Recently I had an opportunity to look at some logs that showed the cipher suites and protocol versions being negotiated for a large cross-section of websites.
I have always wanted to look at data like this and as such have instrumented my own sites to look at it but let’s face it some uber geek blog or security product company website just isn’t going to have representative traffic for the internet at large.
One of the easiest and most useful things to gleam from this data is that the impact of disabling SSL 3.0 is actually quite small.
So of the sampling 2.48% of all SSL/TLS sessions were done with SSL 3.0, if we look at (and believe) the User Agents that negotiated these sessions we see 74.98% of these were Windows clients, the next biggest chunk was Gecko at 16.39%.
| Browser | % |
| Internet Explorer |
74.98% |
| Gecko |
16.39% |
| Apple |
4.12% |
| Playstation |
2.85% |
| Chrome |
1.36% |
| Other |
0.30% |
|
100.00% |
Of these Windows clients 45.45% of them were Windows 2000 or XP but only 6.67% of them were running versions of Internet Explorer that did not support TLS 1.0; this basically boils down the the IE versions before version 7 as this was the first to enable TLS by default. So why did we see the remaining 68.31% of the 2.48% negotiating SSL when they support TLS?
There are a few possible explanations:
- Some TLS implementations will fall back to SSL in the event of a failure, one common example of a failure would be an intermittent TCP connection problem. Basically if this is the case the client had a problem reaching the server and thought it might be related to TLS and so it tried again. In this case its likely that if it had tried with TLS it probably would have succeeded also. It also seems that its likley in this case the user did not get a working experience — the assumption here is that the TCP problems they are experiencing were not a one time thing.
- Some old TLS implementations had problems with TLS extensions as such some TLS implementations added logic to fall back to SSL when they encountered a this extension intolerance, again falling back to TLS (without extensions) would have likely also worked.
- Some enterprises may have used group policy to disable the use of TLS due to the TLS extension intolerance problems (see #2).
- Some clients are lying; they may be crawlers, bots and other such automated agents looking to profile these websites.
So what can we do with this data?
Well for one we can understand what interoperability implications we may encounter by disabling SSL 3.0 on our servers – on the surface the answer is up to 2.48% of clients will not be able to get to our servers.
The real answer is that it’s likely that figure is much smaller, probably half that if not even less than.
OK, so we understand the interoperability impact but why should I care? Well there are a few reasons:
- NIST 140-2 compliance requires disabling SSL 3 ciphers and by disabling SSL 3 you do just that.
- The browsers that only support this decade old protocol are nearly as old and a have a litany of issues of their own.
- TLS has a number of security, performance and deploy-ability enhancing features such such as stronger cipher suites, Session Tickets and SNI that you will benefit from.
Another thing you should ask yourself is did you design your site for these old browsers? If not by leaving SSL 3 enabled you really are not getting much if any benefit since those users who require it would likely not be able to use your site effectively anyways.
When we consider this data I believe the natural conclusion is that disabling SSL 3.0 it is the right thing to do.
Ryan