Quality ramblers rejoice! I’m back for a rare quality ramble. Articles for sorting out SSL configs are aplenty if you’re after nginx or Apache, but for squid they’re sadly lacking. So here we are.
I have a client who has some pokey old squid reverse proxies. They’re running on RHEL5 with Squid 2.6.something and openssl 0.9.8e. Encouraging the client to upgrade those is another battle, but making the most out of what we’ve got does give us a nice challenge. And being a low baseline means that if you have newer packages, you too can bump your ssllabs score up.
So first of all, what’s ssllabs? It’s an online tool hosted and maintained by Qualys, who use it to drum up business for themselves, but they also freely share it. You can use it to perform some security testing against any secure website that’s accessible on the internet, and you can find it here. I’ve been aware of this tool for a while now, but I found it really came into its own after the Heartbleed and POODLE vulnerabilities. It gives a manglement friendly output too, which helps when you’re submitting Change Orders.
So an initial test against a handful of my client’s URL’s was pretty grim reading: F grades across the board with a laundry list of major issues reported. And it was even worse after I compared them to their peers, most of whom had been paying attention to website security. Now, I should point out that the client’s website security isn’t strictly my responsibility, but I am responsible for the Squid config and the underlying OS, so there’s an overlap there between myself and the web services team. They didn’t seem interested in keeping tabs on security, so I simply got proactive. Over time I’ve nursed it up to the B level shown, with a couple more tweaks due to go in soon to cater for the CRIME attack and to begin fixing Forward Secrecy. Beyond that, we need an upgrade to get a new version of OpenSSL and TLSv1.2.
With that background in mind, let’s get to it. First of all, a typical
https_port line in
/etc/squid/squid.conf might look like this:
https_port 443 accel defaultsite=someinternalhost vhost cert=/etc/squid/CertAuth/supersecret.crt key=/etc/squid/CertAuth/supersecret.key options=NO_SSLv2 cipher=DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA
Well, that’s going to get you a lot of alerts. But let’s look at some of the other alerts that you’ll find in your ssllabs report:
Some of these are recommendations, others we simply cannot deal with as our hands are tied by an old version of OpenSSL, but we can deal with some of them. Firstly, Heartbleed: if you haven’t updated OpenSSL, do that NOW. Next, Forward Secrecy, also known as Perfect Forward Secrecy. To mitigate for this, you need to generate a
dhparams.pem file, like so:
openssl dhparam -out dhparams.pem 2048
Note1: the Java clients in the ssllabs test will complain, because they can’t support more than 1024bits. On balance: two old Java versions vs everything else… when people should be upgrading Java? Exactly. You can choose to generate a 1024 bit pem file though, if you want. You’ll just weaken Forward Secrecy across the board.
Note2: I have opted in this example to go for 2048bits, but really, you can go for 4096 if you like. You’ll only break one extra version of Java.
On this host we already have our certs in
/etc/squid/CertAuth, so that seems as good a place as any to store it. And then we append it to each
https_port line in our
squid.conf file. While we’re here, we also want to make some changes to the ciphers and disable SSLv3 and RC4. We can borrow a decent list from an Apache-based article here. So ultimately, each
https_port line should now read like this:
https_port 443 accel defaultsite=someinternalhost vhost cert=/etc/squid/CertAuth/supersecret.crt key=/etc/squid/CertAuth/supersecret.key options=NO_SSLv2,NO_SSLv3,CIPHER_SERVER_PREFERENCE cipher=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4 dhparams=/etc/squid/CertAuth/dhparams.pem
You’ll note a few changes: firstly, we’ve added NO_SSLv3 to mitigate POODLE. I put that one in on day 0, it took the Checkpoint boys three weeks to catch up! We’ve added CIPHER_SERVER_PREFERENCE, and put in a complete cipher suite going from strongest to weakest. We’ve also outright disabled the RC4 cipher to mitigate BEAST, and the EXPORT ciphers to mitigate FREAK.
Update 15/07/16: In versions of Squid newer than around 3.5.1, you may need to use a different declaration,
tls-dh=[curve]:/path/to/dhparams.pem, for example:
tls-dh=prime256v1:/etc/squid/CertAuth/dhparams.pem. This will enable the elliptic curve cipher options. See here and here for more. Note that you may like to add
SINGLE_DH_USE to the options= block. My thanks to Vincent Cardillo for the heads up!
Note that in the old environment that I’m working in, openssl 0.9.8e doesn’t support half of these ciphers, which is fine – it’ll ignore the ones it doesn’t recognise. This really means that we’re getting our
squid.conf file ready to be essentially plug and play when a new RHEL6 or RHEL7 squid platform is stood up.
Finally, TLS Compression. In newer versions of squid, you should be able to add
NO_Compression to the options line, but in older versions like I have, we can use an Apache trick. Append the following to
# Disable TLS Compression
and then restart squid:
service squid restart
And there you have it. A pretty wordy article, resulting in a couple of copy-pastas and you’ll have your squid config in a better position. You can then move-on to the nice-to-haves like HSTS and OCSP Stapling.