Compatibility/interoperability is a good thing. It’s generally good for systems on the Internet to be capable of communicating with as many systems as possible. Unfortunately it’s not always possible as new features sometimes break compatibility with older systems. Sometimes you have systems that are simply broken, for example all the systems with firewalls that block ICMP so that connections hang when the packet size gets too big. Sometimes to take advantage of new features you have to potentially trigger issues with broken systems.
I recently added support for IPv6 to the Linux Users of Victoria server. I think that adding IPv6 support is a good thing due to the lack of IPv4 addresses even though there are hardly any systems that are unable to access IPv4. One of the benefits of this for club members is that it’s a platform they can use for testing IPv6 connectivity with a friendly sysadmin to help them diagnose problems. I recently notified a member by email that the callback that their mail server used as an anti-spam measure didn’t work with IPv6 and was causing mail to be incorrectly rejected. It’s obviously a benefit for that user to have the problem with a small local server than with something like Gmail.
In spite of the fact that at least one user had problems and others potentially had problems I think it’s clear that adding IPv6 support was the correct thing to do.
Table of Contents
SSL Issues
Ben wrote a good post about SSL security [1] which links to a test suite for SSL servers [2]. I tested the LUV web site and got A-.
This blog post describes how to setup PFS (Perfect Forward Secrecy) [3], after following it’s advice I got a score of B!
From the comments on this blog post about RC4 etc [4] it seems that the only way to have PFS and not be vulnerable to other issues is to require TLS 1.2.
So the issue is what systems can’t use TLS 1.2.
TLS 1.2 Support in Browsers
This Wikipedia page has information on SSL support in various web browsers [5]. If we require TLS 1.2 we break support of the following browsers:
The default Android browser before Android 5.0. Admittedly that browser always sucked badly and probably has lots of other security issues and there are alternate browsers. One problem is that many people who install better browsers on Android devices (such as Chrome) will still have their OS configured to use the default browser for URLs opened by other programs (EG email and IM).
Chrome versions before 30 didn’t support it. But version 30 was released in 2013 and Google does a good job of forcing upgrades. A Debian/Wheezy system I run is now displaying warnings from the google-chrome package saying that Wheezy is too old and won’t be supported for long!
Firefox before version 27 didn’t support it (the Wikipedia page is unclear about versions 27-31). 27 was released in 2014. Debian/Wheezy has version 38, Debian/Squeeze has Iceweasel 3.5.16 which doesn’t support it. I think it is reasonable to assume that anyone who’s still using Squeeze is using it for a server given it’s age and the fact that LTS is based on packages related to being a server.
IE version 11 supports it and runs on Windows 7+ (all supported versions of Windows). IE 10 doesn’t support it and runs on Windows 7 and Windows 8. Are the free upgrades from Windows 7 to Windows 10 going to solve this problem? Do we want to support Windows 7 systems that haven’t been upgraded to the latest IE? Do we want to support versions of Windows that MS doesn’t support?
Windows mobile doesn’t have enough users to care about.
Opera supports it from version 17. This is noteworthy because Opera used to be good for devices running older versions of Android that aren’t supported by Chrome.
Safari supported it from iOS version 5, I think that’s a solved problem given the way Apple makes it easy for users to upgrade and strongly encourages them to do so.
Log Analysis
For many servers the correct thing to do before even discussing the issue is to look at the logs and see how many people use the various browsers. One problem with that approach on a Linux community site is that the people who visit the site most often will be more likely to use recent Linux browsers but older Windows systems will be more common among people visiting the site for the first time. Another issue is that there isn’t an easy way of determining who is a serious user, unlike for example a shopping site where one could search for log entries about sales.
I did a quick search of the Apache logs and found many entries about browsers that purport to be IE6 and other versions of IE before 11. But most of those log entries were from other countries, while some people from other countries visit the club web site it’s not very common. Most access from outside Australia would be from bots, and the bots probably fake their user agent.
Should We Do It?
Is breaking support for Debian/Squeeze, the built in Android browser on Android <5.0, and Windows 7 and 8 systems that haven’t upgraded IE as a web browsing platform a reasonable trade-off for implementing the best SSL security features?
For the LUV server as a stand-alone issue the answer would be no as the only really secret data there is accessed via ssh. For a general web infrastructure issue it seems that the answer might be yes.
I think that it benefits the community to allow members to test against server configurations that will become more popular in the future. After implementing changes in the server I can advise club members (and general community members) about how to configure their servers for similar results.
Does this outweigh the problems caused by some potential users of ancient systems?
I’m blogging about this because I think that the issues of configuration of community servers have a greater scope than my local LUG. I welcome comments about these issues, as well as about the SSL compatibility issues.
- [1] https://www.decadent.org.uk/ben/blog/securing-wwwdecadentorguk.html
- [2] https://www.ssllabs.com/ssltest/
- [3] https://blog.qualys.com/ssllabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
- [4] https://blog.qualys.com/ssllabs/2013/03/19/rc4-in-tls-is-broken-now-what
- [5] https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers
It is certainly possible to get an A (PFS with all browsers) without requiring TLS 1.2: .
However, to get there, you have to overwrite the cipher order in the server configuration. To this, end, with Apache, I do
SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite ‘kEECDH+AESGCM:kEDH+AESGCM:kEECDH:kEDH:AESGCM:ALL:+3DES:!EXPORT:!LOW:!MEDIUM:!aNULL:!eNULL’
SSLHonorCipherOrder on
I am not happy with hard-coding the cipher order, since I expect browser writers to spend more time evaluating these decisions than I do. That said,
a) Many security guides on the web recommend overwriting the cipher order, so I am not alone
b) At least my CipherSuite is reasonably general, as opposed to hard-coding ciphers individually. Everybody following these guides that recommend all-manual cipher suites, will have to update their configuration every time a new cipher appears, or an old cipher gets so bad it can’t be considered “HIGH” any more. I don’t think that’s good.
The Mozilla IT security team publishes their own (constantly updated) recommendations for web servers: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
You can choose the level of compatibility you want (modern, intermediate or old). For example, on Libravatar.org, I use the modern config for the main webapp (where you login and upload photos) and intermediate for the mirrors who serve the images to clients.
Ralf: Thanks for the suggestion.
Francois: Thanks for the reference. I copied the SSLCipherSuite that Mozilla recommends for “Modern” systems and got a score of “A” which is good enough for now.
The question is not just about browsers. Think cURL, wget, fetch, ftp, lynx, links, elinks, links+, w3m, dillo, the various Perl, Python, etc. things, openssl, …
OpenSSL 1.x, which introduced TLS 1.2, broke so many things in a backwards-incompatible way that many don’t switch to it (yet).
While “yes, we should really want TLS 1.2†I don’t believe it’s ok to force out TLS 1.0 users yet, unless you have a security level need like a bank or something.