Skip to main content

How-To: Securing SSL Traffic Using a Proxy

January 29, 2014

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.


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.


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.

Related Blogs

June 07, 2018

Quick Tips for Building an Effective AppSec Program – Part 3

This is the last post in my series on creating an effective AppSec program within your organization. In my last post, we discussed the importance of t...

See Details

May 10, 2018

Observations on Smoke Tests – Part 3

While attending one of our technology partner’s security training courses, the instructor presented on their product’s various features and capabiliti...

See Details

May 03, 2018

Getting Started with Postman for API Security Testing: Part 1

Postman is a useful tool used by many developers to document, test and interact with Application Programming Interfaces (APIs). With the ubiquity of A...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy


May 09, 2018

Application Security

Learn how Optiv can help protect your most critical enterprise applications from both internal and external threats.

See Details

July 21, 2015

Network Security Solutions

Learn how we help protect your environment while maintaining connectivity.

See Details

February 06, 2018

What Is SSL Web Inspection and Where Should It Occur? (Part 3)

In parts one and two of this blog series, I provided an overview of SSL web inspection, and dove deeper into how SSL inspection solutions work and met...

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.