It’s been a couple of months since I posted anything, and honestly that’s more down to me being lazy and having nothing worth posting to talk about. But Qualys have updated their SSL Labs to make the use of TLS 1.1 and TLS 1.0 cap the score to a B. This has lead me to once again look at the TLS settings for the various servers that I run. Apache HTTPD is the easiest of server applications that I run to update for this so that’s where I decided to start. Rather than just updating to TLS version 1.2 only it would be nice to use TLS 1.3 as well. However I was mostly running Debian Stretch and out of the box the version of Apache HTTPD included in this release doesn’t support TLS 1.3. Fortunately for me Debian Buster has been out a while, and I have always found Debian upgrades to go smoothly so I decided to run a dist-upgrade, and update the TLS settings on Apache HTTPD.
So the SSL certificate that I used to secure my website (and other things) is no longer trusted by Chrome (as of version 57), and so I have been forced to upgrade to a Lets Encrypt SSL certificate. It's almost as if I could have predicted this state of affairs in advance. At least I can now rest assured that my SSL certs will be easy to keep up to date (I have set up what I believe to be the required automated steps to do just that, time will tell).
So, not very long ago I renewed the SSL certs for my website, I was happy with the changes that StartCom made to their free SSL certificate offering at the time. It turns out, however, that I should start looking at finding an alternative as StartCom are apparently being put on the naughty step. At least Let's Encrypt is up and running now. I'm also looking at changing my e-mail server, but more on that another time (maybe).
So, about a year ago I renewed my SSL certificates, and I was using StartSSL as my certificate provider, because they were free, if a little awkward to use. One of the limitations they placed on the free certs is that they could only be valid for a year. At the time I was interested to see what would become of Let's Encrypt as it promised not only free certificates, but a much easier way to get, and manage those certificates. They went live in April this year. I have been considering setting up my cert through Let's Encrypt, and renewing my SSL certificate was the perfect opportunity to do so, however, I have not got myself into a possition to fully automate the renewal of all the places I use my SSL certificate, so while it is still a manual process, and I got the reminder from StartSSL I figured why not give them another go.
So, I use PlusNet as my ISP. I have an email address with them where they send updates about my account. It's also been used in the past to sign up to various things that I haven't bothered to update to a new email address. PlusNet's email servers do not require authentication to send email from my home connection, which is fair enough really. But they also don't support SSL for authentication from my connection. So my username and password (which is unique to this account) has to be sent in plain text, now as this is to my ISP over my ISP connection (and I trust my own network) it's not the end of the world. However, I also have a shiny smart phone, and that allows me to connect to my own email server, over SSL (that until recently wasn't as secure as it should be) as it should be when connecting over the internet, from untrusted, or unknown networks. It also allows me to use multiple different email inboxes at once. So I could add my PlusNet email address. They even have a handy guide on setting up email on android phones. And that's where the problems start. That guide sets up email without SSL, or TLS, but it requires username and password authentication. So I'd only be able to use it on my home network. What happens if I forget to turn email sync off? My details would be put at risk!
So what should a good sysadmin do? Should I leave the ISP email only on my home PC? Should I take the risk and add the email to my phone anyway?
Well as a paranoid sysadmin I wasn't willing to take the risk. And that was that. But frankly that was annoying me, so I decided to set up an SSL terminator for my ISP email using my own SSL cert. So I can get my email, from my ISP confident in the knowledge that only my ISP can intercept the username and password pair that I use with my ISP. I use non-standard ports for the ISP connections, and listen using stunnel. This would be a problem if I was supporting users as it would add a level of complexity to the instructions I'd have to give them, but as I only have to support myself I can cope.
So, some time ago I had to admit that I needed TLSv1, well time marches on, and I started to look at SSL settings again (largely because my SSL certificate expired, and I needed to replace it, so why not review the SSL settings).
So following my work on fixing CVE-2014-4566 on my website, it turned out that I do indeed need to use lower versions of TLS than 1.2 a revelation that is a little embarrassing to admit. So I have been doing a little playing with the settings, and have tweaked the cipher suite to support TLSv1 TLSv1.1 and TLSv1.2 and only ciphers with forward secrecy.
So another day, another web security vulnerability. Once again a problem on the internet has prompted me to fix something on my home server, in this case the SSLv3 vulnerabilty that has been given the name "POODLE" (seriously who comes up with these names) and it has reminded me that the SSL settings on my server are woefully inadequate.
Given my site is just a personal site I figure there is no real reason to stay with SSLv3 as I don't much care about IE6 users. In fact, the stuff I use it for supports TLSv1.2 so I may as well stick to that, and the older protocols be damned. This does break a large number of older, and mobile clients. But that is their problem.
It's also a good time to play with different cipher suite orders. So I've removed all but those that support forward secrecy (again, this will break stuff, but not the stuff I use so I don't much care).
Obviously the choices I have made here are made in the absence of any pragmatic need to support legacy systems, but that is the beauty of having a personal site rather than a commercial one.