This is like the Gashlycrumb Tinies but for websites:
It’s been interesting to see how websites die — from domain parking pages to timeouts to blank pages to outdated TLS cipher errors, there are a multitude of different ways.
Back in March, I wrote about a dilemma I was facing. I could make the certificates on The Session more secure. But if I did that, people using older Android and iOS devices could no longer access the site:
As a site owner, I can either make security my top priority, which means you’ll no longer be able to access my site. Or I can provide you access, which makes my site less secure for everyone.
In the end, I decided in favour of access. But now this issue has risen from the dead. And this time, it doesn’t matter what I think.
Let’s Encrypt are changing the way their certificates work and once again, it’s people with older devices who are going to suffer:
Most notably, this includes versions of Android prior to 7.1.1. That means those older versions of Android will no longer trust certificates issued by Let’s Encrypt.
This makes me sad. It’s another instance of people being forced to buy new devices. Last time ‘round, my dilemma was choosing between security and access. This time, access isn’t an option. It’s a choice between security and the environment (assuming that people are even in a position to get new devices—not an assumption I’m willing to make).
But this time it’s out of my hands. Let’s Encrypt certificates will stop working on older devices and a whole lotta websites are suddenly going to be inaccessible.
I could look at using a different certificate authority, one I’d have to pay for. It feels a bit galling to have to go back to the scammy world of paying for security—something that Let’s Encrypt has taught us should quite rightly be free. But accessing a website should also be free. It shouldn’t come with the price tag of getting a new device.
Universal access is at the heart of the World Wide Web. It’s also something I value when I’m building anything on the web. Whatever I’m building, I want you to be able to visit using whatever browser or device that you choose.
Just to be clear, that doesn’t mean that you’re going to have the same experience in an old browser as you are in the latest version of Firefox or Chrome. Far from it. Not only is that not feasible, I don’t believe it’s desirable either. But if you’re using an old browser, while you might not get to enjoy the newest CSS or JavaScript, you should still be able to access a website.
Applying the principle of progressive enhancement makes this emminently doable. As long as I build in a layered way, everyone gets access to the barebones HTML, even if they can’t experience newer features. Crucially, as long as I’m doing some feature detection, those newer features don’t harm older browsers.
But there’s one area where maintaining backward compatibility might well have an adverse effect on modern browsers: security.
I don’t just mean whether or not you’re serving sites over HTTPS. Even if you’re using TLS—Transport Layer Security—not all security is created equal.
Take a look at Mozilla’s very handy SSL Configuration Generator. You get to choose from three options:
- Modern. Services with clients that support TLS 1.3 and don’t need backward compatibility.
- Intermediate. General-purpose servers with a variety of clients, recommended for almost all systems.
- Old. Compatible with a number of very old clients, and should be used only as a last resort.
Because I value universal access, I should really go for the “old” setting. That ensures my site is accessible all the way back to Android 2.3 and Safari 1. But if I do that, I will be supporting TLS 1.0. That’s not good. My site is potentially vulnerable.
Alright then, I’ll go for “intermediate”—that’s the recommended level anyway. Now I’m no longer providing TLS 1.0 support. But that means some older browsers can no longer access my site.
This is exactly the situation I found myself in with The Session. I had a score of A+ from SSL Labs. I was feeling downright smug. Then I got emails from actual users. One had picked up an old Samsung tablet second hand. Another was using an older version of Safari. Neither could access the site.
Sure enough, if you cut off TLS 1.0, you cut off Safari below version six.
Alright, then. Can’t they just upgrade? Well …no. Apple has tied Safari to OS X. If you can’t upgrade your operating system, you can’t upgrade your browser. So if you’re using OS X Mountain Lion, you’re stuck with an insecure version of Safari.
Fortunately, you can use a different browser. It’s possible to install, say, Firefox 37 which supports TLS 1.2.
On desktop, that is. If you’re using an older iPhone or iPad and you can’t upgrade to a recent version of iOS, you’re screwed.
This isn’t an edge case. This is exactly the kind of usage that iPads excel at: you got the device a few years back just to do some web browsing and not much else. It still seems to work fine, and you have no incentive to buy a brand new iPad. And nor should you have to.
In that situation, you’re stuck using an insecure browser.
As a site owner, I can either make security my top priority, which means you’ll no longer be able to access my site. Or I can provide you access, which makes my site less secure for everyone. (That’s what I’ve done on The Session and now my score is capped at B.)
What I can’t do is tell you to install a different browser, because you literally can’t. Sure, technically you can install something called Firefox from the App Store, or you can install something called Chrome. But neither have anything to do with their desktop counterparts. They’re differently skinned versions of Safari.
Apple refuses to allow browsers with any other rendering engine to be installed. Their reasoning?
Security.
Even using a strict cookie policy won’t help when Facebook and Google are using TLS to fingerprint users. Time to get more paranoid:
HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.
All the books, Montag.
If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.
How a certificate with extended validation makes it easier to phish. But I think the title could be amended—here’s what’s really broken:
On Safari, the URL is completely hidden! This means the attacker does not even need to register a convincing phishing domain. They can register anything, and Safari will happily cover it with a nice green bar.
This graph warms the cockles of my heart. It’s so nice to see a genuinely good project like Let’s Encrypt come in and upset the applecart of a sluggish monopolistic industry.
Things are looking good for HTTPS.
Following from that great post about the “zone of death” in browsers, Eric Law looks at security and trust in a world where certificates are free and easily available …even to the bad guys.
Details of The Guardian’s switch to HTTPS.
In the latest issue of Justin’s excellent Responsive Web Design weekly newsletter, he includes a segment called “The Snippet Show”:
This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.
<meta name="viewport" content="width=device-width, initial-scale=1">
The viewport value for the meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the meta viewport gubbins that they made up.
That was nine years ago. These days, if you’re building a responsive website, you still need to include that meta element.
That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.
Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).
There are other browser default behaviours that might someday change. Right now, if I type example.com into a browser, it will first attempt to contact http://example.com rather than https://example.com. That means the example.com server has to do a redirect, costing the user valuable time.
You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for HTTPS instead of HTTP? I don’t think that will happen anytime soon, but someday …someday.
Slowly but surely the web is switching over to HTTPS. The past year shows a two to threefold increase.
One more reason to make the switch to HTTPS.
I’ve been updating my book sites over to HTTPS:
They’re all hosted on the same (virtual) box as adactio.com—Ubuntu 14.04 running Apache 2.4.7 on Digital Ocean. If you’ve got a similar configuration, this might be useful for you.
First off, I’m using Let’s Encrypt. Except I’m not. It’s called Certbot now (I’m not entirely sure why).
I installed the Let’s Encertbot client with this incantation (which, like everything else here, will need root-level access so if none of these work, retry using sudo in front of the commands):
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
Seems like a good idea to put that certbot-auto thingy into a directory like /etc:
mv certbot-auto /etc
Rather than have Certbot generate conf files for me, I’m just going to have it generate the certificates. Here’s how I’d generate a certificate for yourdomain.com:
/etc/certbot-auto --apache certonly -d yourdomain.com
The first time you do this, it’ll need to fetch a bunch of dependencies and it’ll ask you for an email address for future reference (should anything ever go screwy). For subsequent domains, the process will be much quicker.
The result of this will be a bunch of generated certificates that live here:
/etc/letsencrypt/live/yourdomain.com/cert.pem/etc/letsencrypt/live/yourdomain.com/chain.pem/etc/letsencrypt/live/yourdomain.com/privkey.pem/etc/letsencrypt/live/yourdomain.com/fullchain.pemNow you’ll need to configure your Apache gubbins. Head on over to…
cd /etc/apache2/sites-available
If you only have one domain on your server, you can just edit default.ssl.conf. I prefer to have separate conf files for each domain.
Time to fire up an incomprehensible text editor.
nano yourdomain.com.conf
There’s a great SSL Configuration Generator from Mozilla to help you figure out what to put in this file. Following the suggested configuration for my server (assuming I want maximum backward-compatibility), here’s what I put in.
Make sure you update the /path/to/yourdomain.com part—you probably want a directory somewhere in /var/www or wherever your website’s files are sitting.
To exit the infernal text editor, hit ctrl and o, press enter in response to the prompt, and then hit ctrl and x.
If the yourdomain.com.conf didn’t previously exist, you’ll need to enable the configuration by running:
a2ensite yourdomain.com
Time to restart Apache. Fingers crossed…
service apache2 restart
If that worked, you should be able to go to https://yourdomain.com and see a lovely shiny padlock in the address bar.
Assuming that worked, everything is awesome! …for 90 days. After that, your certificates will expire and you’ll be left with a broken website.
Not to worry. You can update your certificates at any time. Test for yourself by doing a dry run:
/etc/certbot-auto renew --dry-run
You should see a message saying:
Processing /etc/letsencrypt/renewal/yourdomain.com.conf
And then, after a while:
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded.
You could set yourself a calendar reminder to do the renewal (without the --dry-run bit) every few months. Or you could tell your server’s computer to do it by using a cron job. It’s not nearly as rude as it sounds.
You can fire up and edit your list of cron tasks with this command:
crontab -e
This tells the machine to run the renewal task at quarter past six every evening and log any results:
15 18 * * * /etc/certbot-auto renew --quiet >> /var/log/certbot-renew.log
(Don’t worry: it won’t actually generate new certificates unless the current ones are getting close to expiration.) Leave the cronrab editor by doing the ctrl o, enter, ctrl x dance.
Hopefully, there’s nothing more for you to do. I say “hopefully” because I won’t know for sure myself for another 90 days, at which point I’ll find out whether anything’s on fire.
If you have other domains you want to secure, repeat the process by running:
/etc/certbot-auto --apache certonly -d yourotherdomain.com
And then creating/editing /etc/apache2/sites-available/yourotherdomain.com.conf accordingly.
I found these useful when I was going through this process:
That last one is good if you like the warm glow of accomplishment that comes with getting a good grade:
For extra credit, you can run your site through securityheaders.io to harden your headers. Again, not as rude as it sounds.
You know, I probably should have said this at the start of this post, but I should clarify that any advice I’ve given here should be taken with a huge pinch of salt—I have little to no idea what I’m doing. I’m not responsible for any flame-bursting-into that may occur. It’s probably a good idea to back everything up before even starting to do this.
Yeah, I definitely should’ve mentioned that at the start.
For your information, the Let’s Encrypt client is now called Certbot for some reason.
Carry on.
Robert walks through the process he went through to get HTTPS up and running on his Media Temple site.
If you have any experience of switching to HTTPS, please, please share it.
Finally! An article about moving to HTTPS that isn’t simply saying “Hey, it’s easy and everyone should do it!” This case study says “Hey, it’s hard …and everyone should do it.”
This is useful if you’re making the switch to HTTPS: choose your web server software and version to generate a configuration file.
Remember when I mentioned that you can get free certificates from Amazon now? Well, Oliver has written an in-depth step-by-step description of how he got his static site all set up with HTTPS.
More of this please! Share your experiences with moving to TLS—the more, the better.
If you’re hosting with Amazon, you now get HTTPS for free.