Proxies breaking up SSL connections? Yes, all the time…

Some months ago I was wondering why some Firefox installations appear to not support strong encryption. After analyzing the SSL handshakes on one of the filter download servers used by Adblock Plus, I am now mostly confident that the reason is proxy servers essentially conducting Man-in-the-Middle (MitM) attacks. Normally, a proxy server can only forward SSL data to its destination, it can neither modify nor read the data due to encryption. MitM proxies however pose as the destination server which allows them to manipulate the data in any way they like. For that they have to encrypt the communication with a certificate that is valid for the destination server, usually this happens by installing a new root certificate on the client’s computer.

I used ssldump to record 3294 SSL handshakes. Not a terribly large sample, yet it already contained lots of entries where the client’s SSL support didn’t match the user agent from the web server logs:

  • Seven corporate proxies seem to be breaking up SSL connections of the company employees.
  • A program to provide schools with Internet access apparently routes all traffic through a MitM proxy.
  • A university proxy snoops in the SSL traffic.
  • A government agency has to check all outgoing data, even when encrypted.
  • An ISP seems to route all customer traffic through a MitM proxy (not sure how they pulled it off but it’s China so everything is possible).
  • Lots of people use Google AppEngine as a MitM proxy, maybe without even knowing that.
  • Six users seem to be running MitM proxies on their computer, either intentionally or due to a malware infection.
  • Three requests associated with Android devices are strange: either the SSL support of these devices is very outdated despite Android 4.2/4.3 (even SSLv3 used in one case) or a local MitM proxy is running there.

If that sample is representative in any way, it would mean that roughly 0.5% of the internet users are behind a proxy server that will intercept their encrypted data. Why is that a problem?

  • 0.5% might not sound like much but if you apply that to the general Internet population then we are talking about millions of people. That’s millions of people who might be wrongly assuming that the lock icon next to the website address is protecting them.
  • These proxies create a single point of failure: an attacker doesn’t need to tediously infect computers one by one if he can simply control the proxy server and intercept all data there.
  • While all browsers updated their SSL support a while ago to mitigate issues like the BEAST attack, proxy servers didn’t. Only one of the proxy servers I found used TLS 1.1, the rest of them used TLS 1.0 and one (a corporate proxy protecting a large network) even SSLv3.
  • As a webmaster, you cannot just look at the browser versions of your visitors to decide what your webserver needs to support. For example, Security Labs recommends disabling SSLv3 support but it turns out that you might lock out more users than just those using Internet Explorer 6.

For reference, how did I recognize the browsers in the ssldump output? This turned out to be pretty simple, each browser has its very distinct list of supported ciphers that it sends to the server. Conveniently, that’s the very first packet that ssldump will record for a connection. For Firefox 29 it looks like this:

     ClientHello
        Version 3.3 
        cipher suites
        Unknown value 0xc02b
        Unknown value 0xc02f
        Unknown value 0xc00a
        Unknown value 0xc009
        Unknown value 0xc013
        Unknown value 0xc014
        Unknown value 0xc012
        Unknown value 0xc007
        Unknown value 0xc011
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        Unknown value 0x45
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        Unknown value 0x88
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0x41
        TLS_RSA_WITH_AES_256_CBC_SHA
        Unknown value 0x84
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5

Chrome 35 sends a different list:

      ClientHello
        Version 3.3 
        cipher suites
        Unknown value 0xcc14
        Unknown value 0xcc13
        Unknown value 0xc02b
        Unknown value 0xc02f
        Unknown value 0x9e
        Unknown value 0xc00a
        Unknown value 0xc009
        Unknown value 0xc013
        Unknown value 0xc014
        Unknown value 0xc007
        Unknown value 0xc011
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        Unknown value 0x9c
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5

Depending on the Firefox or Chrome version you might get a different list, the SSL support in the browsers evolved. In fact, even the Chromium-based Opera and YandexBrowser tweak the SSL support and send a distinctly different list. Note “Version 3.3” above, this means TLS 1.2 support (“Version 3.0” is SSLv3 and “Version 3.1” stands for TLS 1.0). For comparison, here is the output for one of the proxies:

SSLv2 compatible client hello
  Version 3.1 
  cipher suites
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA  
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA  
  TLS_RSA_WITH_AES_256_CBC_SHA  
  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA  
  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA  
  TLS_RSA_WITH_3DES_EDE_CBC_SHA  
  SSL2_CK_3DES  
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA  
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA  
  TLS_RSA_WITH_AES_128_CBC_SHA  
  TLS_RSA_WITH_IDEA_CBC_SHA  
  SSL2_CK_IDEA  
  SSL2_CK_RC2  
  TLS_RSA_WITH_RC4_128_SHA  
  TLS_RSA_WITH_RC4_128_MD5  
  SSL2_CK_RC4  
  TLS_DHE_RSA_WITH_DES_CBC_SHA  
  TLS_DHE_DSS_WITH_DES_CBC_SHA  
  TLS_RSA_WITH_DES_CBC_SHA  
  SSL2_CK_DES  
  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  
  TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  
  TLS_RSA_EXPORT_WITH_DES40_CBC_SHA  
  TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5  
  SSL2_CK_RC2_EXPORT40  
  TLS_RSA_EXPORT_WITH_RC4_40_MD5  
  SSL2_CK_RC4_EXPORT40  
  Unknown value 0xff

This particular proxy is still compatible to SSLv2 which is no longer considered secure. In fact, Mozilla disabled SSLv2 support staring with Firefox 8 which was released in November 2011. Other browser vendors did it years ago as well.

Comments

  • Michael Kaply

    I don’t know if you’re seeing this yet, but I have heard from adware companies that some are giving up on extensions and installing proxy servers on people’s machines and then redirecting the browsers through those proxy servers to serve ads.

    Maybe that’s some of what you are seeing.

    Wladimir Palant

    Yes, some of the proxies running on user’s machine might be that. Of course, there are quite a few possibilities there. What comes to mind is security software that wants to check SSL traffic at any cost, developer tools like Burp Proxy or even a local caching proxy (not sure whether anybody is still doing that).

  • glandium

    Note a non negligible population is running Firefox versions as old as 3.6. Considering some sites like to screw up users of old browsers by UA checking while their site works just fine, I wouldn’t be surprised they’d change their UA. Also, there are companies where (old) Firefox versions are installed with specific settings. Those settings may e.g. reenable SSLv2 for some reason (one of which could very well be that it was necessary when Mozilla turned it off by default, and was left this way since then).
    I wouldn’t be surprised if that and other similar scenarios account for more of what you observed than MitM attacks.

    Wladimir Palant

    Adblock Plus is also sending parameters indicating the platform it is running on – and it matched the UA. So I don’t think UA sniffing was playing an important role here. Also, in most cases the ciphers were really nothing like what a browser would send, IMHO not even an outdated one.

  • d

    I know this post is old, but I found it just now.

    A lot of companies are using SSL-intercepting filtering proxies, for one reason or another. Some are just overzealous, others have to do it because of contract requirements with customers or partners or, much more important, protection of minors, which is mandatory eg. in Germany if a company has apprentices who are allowed to access the internet. I’m an IT pro (infrastructure consulting) and quite a few of my customers are using SSL interception. Usually, larger companies are good at keeping their proxies up-to-date. Smaller ones, however, are more lenient and use ages old hard- and software, unknowingly creating a greater security hazard than they had without the proxy. And they refuse to update, mostly due to cost – and because “why, it works”.

    Like it or not, SSL intercepting proxies are not going away.

    The sad part is that, for example, Firefox devs seem to ignore this fact (or take an arrogant approach aka “get rid of that proxy”). Firefox accepts only certificates from built-in trusted CAs for updating itself or its addons, no user-added trusts (that’s hardcoded, afaik). So Firefox users behind forced SSL-intercepting proxies are mostly using outdated versions of the browser and any addons that they might have managed to install one way or another. One more nail in FFs coffin when it comes to corporate use. Sadly.

    Getting back on topic, I do like the fact that at least ABP can update its filter lists behind an SSL intercepting proxy. Too bad that ABP itself can’t be updated.