How-To: Securing SSL Traffic Using a Proxy

By Ryan Teegarden ·

SSL traffic should be able to be considered secure, but there are some concerns that can cause the traffic to not be as secure as it could be. Having to secure many clients with multiple browser types can be extremely difficult. One way to combat this difficulty is to utilize an SSL-aware proxy.

Browser Trust and PKI

SSL security in the browser is based around a centralized model of trust. The browser has many certificate authorities that it trusts to validate server and user certificates. In most browsers, the list of trusted certificate authorities is either provided by the operating system or the browser itself.

This trust is created by chaining up to a Root Certificate Authority. The level of trust can only be applied to the lowest security in the chain. If there is a breach on any level of the chain, all of the security the PKI has provided is broken. Because trust is across all certificates in the trusted store, any chain compromise may go undetected.

One venue for compromise could be the addition of a root certificate into the trusted root store. This would allow for users to not know that they are communicating with a site that they would not normally trust.

Windows, Internet Explorer and Chrome utilize the operating system’s certificate store; local and certificates pushed through group policy. Firefox uses its own certificate store that can be auto-populated with a certificate. Once a rouge certificate is inserted into any of the trusted stores, that certificate could be used to create a man-in-the-middle attack on the SSL traffic and could potentially not be noticed. 

Another part of the security formula for PKI is the use of revocation information. Many of the current browsers do not use revocation information properly. Many times, if unavailable, revocation information is completely ignored. This would allow a user to potentially go to a site that has been revoked by the Certificate Authority without warning. 

One more thing that can defeat all of the security that has been implemented in the browsers is the users themselves. If users ignore browser warnings and can continue to insecure sites after accepting a warning, the security implemented is able to be bypassed. This would allow for a user to go to an end site that has potentially been compromised.

Solutions

Utilizing an SSL-aware proxy can mitigate many of the security issues discussed. It can combat client misconfigured client settings and support stronger connections. Keeping track of all of the settings of the Certificate Authority and SSL settings of all the browsers across an organization can be a very difficult task.

If the proxy can understand SSL connections and can determine if there is something wrong in the trust chain, the security should be implemented there. The proxy can be set up to have a set list of controlled trusted certificate authorities. 

The proxy should also be utilized to properly check for revocation (through CRL or OCSP). If implemented properly, the security can be enforced at the proxy, and the user will not have the option to bypass the controls. Enforcing at the proxy also allows for the security to be set for all browsers homogenously. All users and browsers can be forced to use the same settings.

Securing the SSL trust chain will not prevent attacks against the SSL ciphers being used. If destination sites use insecure protocols, those protocols could be susceptible to attack if the client allows them. This can also be mitigated on the proxy by setting what cyphers and connection attributes are allowed. One thing to consider doing at the proxy is disabling SSL version 2.0, and TLS 1.0 (if possible) to further secure browser traffic. Also, consider disabling weak ciphers that could cause security issues.

Conclusion

Further securing of SSL traffic should be done in the corporate environment. Using a proxy can assist with it. This will not secure the traffic before and after the SSL connection, but it will secure the transfer from the proxy to the server.