When Good HTTPS Goes Bad

In this great age of computer security, few can argue that protecting your users from harmful content on the web is a must. Since nearly the beginning of the Internet, system administrators have been using web proxies to help conserve bandwidth, and control browsing habits of users. Today most security administrators have deployed a secure web proxy of some kind or another. These units, regardless of vendor, offer many advantages over a simple proxy. Advantages like granular access policies and HTTPS interception/inspection. No matter which vendor you choose to partner with for your web content filter or WCF if you prefer, intercepting and decrypting SSL is not perfect; at least for the foreseeable future. This is because HTTPS really isn’t designed to be intercepted, and therefore interception is in a sense; a man in the middle attack being carried out by the WCF. For this reason when you deploy your WCF in your network, be that explicit proxy or transparent (WCCP) proxy, some piece of software will break. When this happens you can use the troubleshooting steps below to see what has gone wrong. This is by no means an exhaustive list of troubleshooting steps, but it is a start.

Why did it break? How can I fix it?

The first thing you will need to determine is why the application is not working, and what can be done to fix the broken application or service. In many cases it comes down to one of the following security enhancements offered by most WCF’s on the market today:

Authentication – In the case of an authentication issue it is possible that the application cannot pass your computer credentials to the proxy in the same way that your web browser can. In these cases check to see if you can manually enter your credentials directly into the program. In most cases you may also have to use an explicit proxy as opposed to a transparent proxy. If this doesn’t work, or just doesn’t work for you, your proxy likely allows you to create a policy in which authentication is not required to a specific destination by IP address or FQDN.

Categorization – This one is going to be very simple. This issue occurs when your destination is being black listed because it has been incorrectly categorized by your proxy. You will likely see evidence of this in the logs of your WCF. To fix this simply put the site in the proper category, or if you wish simply white list the site all together.

Reputation Filtering – Most vendors of a WCF product offering usually have a reputation service that allows dynamic re-categorization of sites based on factors like; content, vulnerabilities, and malware. In these cases it is best to ensure that these are false positives before making any changes. Check with multiple sources, and once you are sure the site is, in fact, legitimate contact your vendors reputation service to have its ranking re-evaluated. If time is of the essence, which is usually the case, you can white list the site within your WCF to avoid future incidents (though it is not recommended as the service exists as a layer of security.)

Server Certificate Errors – Server SSL certificates are the technology upon which all SSL technology relies upon. For the sake of time I will simply say that when you run into a server side certificate problem your WCF will display a block page which will state the reason why the certificate was rejected. If it appears that the server certificate has expired you may want to investigate to ensure you are reaching the proper site. If the site looks legitimate be sure to check the clock on your WCF to ensure that the time is correct, even a few hours has been seen to affect this. If the Certificate has an untrusted root CA; establish trust with the root CA and you’ll be back surfing in no time. If you happen to visit a site which uses a wildcard certificate you will find it difficult to proxy this page. Currently in a transparent environment like WCCP you will have to tunnel directly to the site which is issuing the wildcard certificate. This is because WCCP passes all requests by destination IP, not FQDN. In a WCCP environment your proxy uses the certificate name to take you to the page requested, but with a wildcard the WCF cannot determine the FQDN, and will therefore drop to a warning it could not reach your destination.

Client Certificates – Some more security conscious sites such as banking, personal finance, security, or medical sites may authenticate users with client certificates to achieve a two factor login. In cases where a client must present a certificate to the server, you must do a direct tunnel for that site.

Application data via a proxy port – Sometimes you will run into a web application or desktop executables that simply breaks when you run it in a proxy environment. These applications tend to wrap their application data, which is non-http data, in SSL. When a WCF sees this, they tend to treat this data as erroneous or will be unable to scan the packet, and will drop it by default. You can determine if that is what is happening by looking in the logs of your WCF for errors indicating problems scanning data. When you have these applications, you almost always will have to bypass your proxy altogether. One of the best ways to do this is to attempt an ICAP bypass based on the destination of the SSL connection. With this method you will still point or redirect your data to the proxy, but it will not attempt to run any checks on that data, and simply forward it to its destination.

There is no perfect guide or guaranteed methods to troubleshooting HTTPS proxy issues, but the list above constitutes a strong start. If you have more tips or questions, post them in the comments and I will do my very best answer each one.

Cody Bowen

Leave a Reply

Your email address will not be published. Required fields are marked *