Tags: tls

Installing Letsencrypt on Ubuntu 14.04 and nginx | gablaxian.com

If you’re planning the move to TLS and your server is on Digital Ocean running Nginx, Graham’s here to run you through the (surprisingly simple) process.

Taking Let’s Encrypt for a Spin - TimKadlec.com

Tim outlines the process for getting up and running with HTTPS using Let’s Encrypt. Looks like it’s pretty straightforward, which is very, very good news.

I’m using the Salter Cane site as a test ground for this. I was able to get everything installed fairly easily. The tricky thing will be having some kind of renewal reminder—the certificates expire after three months.

Still, all the signs are good that HTTPS is about to get a lot less painful.

More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson

Aaron collects some recent examples that demonstrate

1. why we should use HTTPS and
2. why we should use progressive enhancement.

Mozilla—like Google before them—have announced their plans for deprecating HTTP in favour of HTTPS. I’m all in favour of moving to HTTPS. I’ve done it myself here on adactio.com, on thesession.org, and on huffduffer.com. I have some concerns about the potential linkrot involved in the move to TLS everywhere—as outlined by Tim Berners-Lee—but still, anything that makes the work of GCHQ and the NSA more difficult is alright by me.

But I have a big, big problem with Mozilla’s plan to “encourage” the move to HTTPS:

Gradually phasing out access to browser features.

Requiring HTTPS for certain browser features makes total sense, given the security implications. Service Workers, for example, are quite correctly only available over HTTPS. Any API that has access to a device sensor—or that could be used for fingerprinting in any way—should only be available over HTTPS. In retrospect, Geolocation should have been HTTPS-only from the beginning.

But to deny access to APIs where there are no security concerns, where it is merely a stick to beat people with …that’s just wrong.

This is for everyone. Not just those smart enough to figure out how to add HTTPS to their site. And yes, I know, the theory is that is that it’s going to get easier and easier, but so far the steps towards making HTTPS easier are just vapourware. That makes Mozilla’s plan look like something drafted by underwear gnomes.

The issue here is timing. Let’s make HTTPS easy first. Then we can start to talk about ways of encouraging adoption. Hopefully we can figure out a way that doesn’t require Mozilla or Google as gatekeepers.

Sven Slootweg outlines the problems with Mozilla’s forced SSL. I highly recommend reading Yoav’s post on deprecating HTTP too. Ben Klemens has written about HTTPS: the end of an era …that era being the one in which anyone could make a website without having to ask permission from an app store, a certificate authority, or a browser manufacturer.

On the other hand, Eric Mill wrote We’re Deprecating HTTP And It’s Going To Be Okay. It makes for an extremely infuriating read because it outlines all the ways in which HTTPS is a good thing (all of which I agree with) without once addressing the issue at hand—a browser that deliberately cripples its feature set for political reasons.

Enabling https SSL on your site | Surf the Dream

Justin is at Indie Web Camp Germany with me and he’s been converting Am I Responsive? to https—here’s his write-up.

HTTPS

François is here at Indie Web Camp Germany helping out anyone who wants to get their site running on https. He wrote this great post to get people started.

TLS Everywhere, not https: URIs - Design Issues

This is a really good point from Tim Berners-Lee: there’s no good reason why switching to TLS should require a change of URLs from http:// to https://

HTTPSWatch

Tracking the state of TLS support on prominent websites. It doesn’t look great, particularly in the States.

HTTP/2.0 - The IETF is Phoning It In - ACM Queue

There are some good points here comparing HTTP2 and SPDY, but I’m mostly linking to this because of the three wonderful opening paragraphs:

A very long time ago —in 1989 —Ronald Reagan was president, albeit only for the final 19½ days of his term. And before 1989 was over Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett had died.

In the long run, the most memorable event of 1989 will probably be that Tim Berners-Lee hacked up the HTTP protocol and named the result the “World Wide Web.” (One remarkable property of this name is that the abbreviation “WWW” has twice as many syllables and takes longer to pronounce.)

Tim’s HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six years later, my laptop CPU is a hundred times faster and has a thousand times as much RAM as Tim’s machine had, but the HTTP protocol is still the same.

Tim Berners-Lee is quite rightly worried about linkrot:

The disappearance of web material and the rotting of links is itself a major problem.

He brings up an interesting point that I hadn’t fully considered: as more and more sites migrate from HTTP to HTTPS (A Good Thing), and the W3C encourages this move, isn’t there a danger of creating even more linkrot?

…perhaps doing more damage to the web than any other change in its history.

I think that may be a bit overstated. As many others point out, almost all sites making the switch are conscientious about maintaining redirects with a 301 status code.

(There’s also a similar 308 status code that I hadn’t come across, but after a bit of investigating, that looks to be a bit of mess.)

Anyway, the discussion does bring up some interesting points. Transport Layer Security is something that’s handled between the browser and the server—does it really need to be visible in the protocol portion of the URL? Or is that visibility a positive attribute that makes it clear that the URL is “good”?

And as more sites move to HTTPS, should browsers change their default behaviour? Right now, typing “example.com” into a browser’s address bar will cause it to automatically expand to http://example.com …shouldn’t browsers look for https://example.com first?

All good food for thought.

There’s a Google Doc out there with some advice for migrating to HTTPS. Unfortunately, the trickiest part—getting and installing certificates—is currently an owl-drawing tutorial, but hopefully it will get expanded.

If you’re looking for even more reasons why enabling TLS for your site is a good idea, look no further than the latest shenanigans from ISPs in the UK (we lost the battle for net neutrality in this country some time ago).

BT just inserted a popup into someone’s site, encouraging me to switch on content filtering. That is Very Not Cool. pic.twitter.com/QMnLRawsNW

— David Thompson (@fatbusinessman) December 30, 2014

They can’t do that to pages served over HTTPS.

bramus/mixed-content-scan

A really handy command-line tool that scans your site for mixed content — very useful if you’re making the switch from http to https.

Let’s Encrypt

This is a great development! The EFF are working on a creating a new certificate authority that will issue certs for free.

I am so happy that the certificate authority racket is getting this shake-up.

Embracing HTTPS - NYTimes.com

A friendly challenge from The Grey Lady for news sites to enable TLS.

Make a commitment to have your site fully on HTTPS by the end of 2015 and pledge your support with the hashtag #https2015.

The Netflix Tech Blog: Message Security Layer: A Modern Take on Securing Communication

Netflix are going full 927 on TLS.

This is a terrible idea.

Introducing Universal SSL

Great news from Cloudflare—https endpoints by default!

This means that if you’re planning on switching on TLS for your site, but you’re using Cloudflare as a CDN, you’ve got one less thing to change (and goodness knows you’re going to have enough to do already).

I really like their reasoning for doing this, despite the fact that it might mean that they take a financial hit:

Having cutting-edge encryption may not seem important to a small blog, but it is critical to advancing the encrypted-by-default future of the Internet. Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web. In other words, ensuring your personal blog is available over HTTPS makes it more likely that a human rights organization or social media service or independent journalist will be accessible around the world. Together we can do great things.

Anne’s Blog

Anne is documenting his process of going https:

1. TLS: first steps
2. TLS: issues with StartSSL
3. TLS: issues with DreamHost
4. TLS: deploy HSTS
5. TLS: next steps

I’m really glad he’s doing this.

As promised at Indie Web Camp, here are the steps I took to make my site https:// only.

Now, here’s the thing with any of these walkthroughs; they’re all very specific to host/server combo in question. My particular combination is:

1. Hosting on a Digital Ocean virtual machine running Ubuntu 14.04 (typing lsb_release -a on the server will tell you which version of Ubuntu you’re running).
2. Running Apache 2.4.7 (typing apache2 -v will tell you which version of Apache is running).

If you’re using another flavour of Linux, or running Nginx, this walkthrough will probably not help you. You’ll also need admin access to the server. If you’re on shared hosting, you may well be screwed from the get-go.

To start with, you need to get your magic certificates from a Certificate Authority. So the first question is: who is a good Certificate Authority?

Choose a Certificate Authority

There is no such thing as a good Certificate Authority.

It’s a racket.

The best you can hope for is to deal with a Certificate Authority that doesn’t charge too much and doesn’t make the process as painful as applying a power drill to your teeth.

My pain was mitigated by my DNS provider, DNSimple. They have a one-clickish process for applying for a certificate. They charge $20 a year for a single hostname, which is not too bad. If that’s still too rich for your blood, you can look into navigating the interface at StartSSL. Good luck with that.

Until last week, DNSimple were using RapidSSL to issue those single-hostname certificates. RapidSSL still issues SHA-1 certificates by default, which is not good. But after a little prompting, DNSimple switched to Comodo for their single-hostname certificates, which means you can get yummy SHA256 encryption.

Make a private key and CSR

DNSimple can even take care of generating a private key and a Certificate Signing Request (the two chunks of encrypted gibberish you need to send to the Certificate Authority to get your certificate). Otherwise you’ll need to generate those for yourself. To do that, ssh into your server and run this, swapping out yourdomain_com for, you guessed it, your domain:

openssl req -new -newkey rsa:2048 -nodes -keyout /etc/ssl/private/yourdomain_com.key -out /etc/ssl/certs/yourdomain_com.csr

..and answer the probing questions that your nosy server will ask of you. You’ll then have two files:

/etc/ssl/private/yourdomain_com.key
/etc/ssl/certs/yourdomain_com.csr

You can then copy and paste the contents of those files when you’re applying for a certificate from your CA of choice. I can’t walk you through that process because, like I said, I managed to skip over it completely by having DNSimple do all the work.

I still had to put the private key on my server so I created the file:

nano /etc/ssl/private/yourdomain_com.key

And then I pasted the private key in there, hit ctrl o and then hit enter to write out the file, followed by ctrl x to close it.

(If some of these command line things don’t work for you, try prefixing them with sudo, try again, and enter your password when prompted.)

See how this is getting more and more specific to my particular combination? Now I’m talking about installing a Comodo certificate (acquired through DNSimple) on Apache 2.4 on Ubuntu 14. If you’re using a Certificate Authority other than Comodo, the next step won’t mean much to you.

Install your certificate on your server

There’s some documentation on the Comodo site for this step. At this point, you should have received a zip file from Comodo with four files:

1. AddTrustExternalCARoot.crt
2. COMODORSAAddTrustCA.crt
3. COMODORSADomainValidationSecureServerCA.crt
4. yourdomain_com.crt

Open a text editor on your computer and create a new file by copying and pasting the contents of these files in this order:

1. COMODORSADomainValidationSecureServerCA.crt followed by
2. COMODORSAAddTrustCA.crt follwed by
3. AddTrustExternalCARoot.crt

On your server, create a new file by typing:

nano /etc/ssl/certs/yourdomain_com.ca-bundle

Paste in the combined contents of the text file from your computer. Hit ctrl o (followed by enter) to write out the file and ctrl x to close it.

That leaves one file, which is your actual certificate, yourdomain_com.crt

On your server, type:

nano /etc/ssl/certs/yourdomain_com.crt

Copy and paste the contents from the certificate file (yourdomain_com.crt) in there. Hit ctrl o to write out the file and ctrl x to close it.

Set up https on Apache

Remember, this is for Apache 2.4. Things will be subtly different on previous versions. For instance, on Apache 2.4, all the files in /etc/apache2/sites-available must end with .conf; that wasn’t the case with previous versions.

First things first. You need to enable the ssl module for Apache. On your server, type:

a2enmod ssl

(Again, if that doesn’t work straight away, try prefixing it with sudo.)

Now restart Apache:

service apache2 restart

Your Apache server is now capable of serving over https, but you still need to give it more details.

Go into the sites-available directory by typing:

cd /etc/apache2/sites-available

You can see all the files in this folder by typing ls. I’m going to assume that you’ve got the server serving up just one site and that the details of that site are in the 000-default.conf file which serves up your site over port 80. You’ll want to copy any details you have set up in 000-default.conf over to default-ssl, but with the difference that the port number is 443. The top of your default-ssl file should look something like this:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
            ServerAdmin you@yourdomain.com
            ServerName yourdomain.com
            ServerAlias www.yourdomain.com
            DocumentRoot /var/www

It might be that your DocumentRoot is /var/www/html. That’s fine (as long as that’s where your website’s files are actually sitting).

Oh, I should have mentioned: the way that you can examine (and edit) that default-ssl.conf is by typing:

nano /etc/apache2/sites-available/default-ssl.conf

Comment out these two lines by placing a # at the start of each line:

#SSLCertificateFile     /etc/ssl/certs/ssl-cert-snakeoil.pem
#SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Right under those lines, add these:

SSLCertificateFile    /etc/ssl/certs/yourdomain_com.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain_com.key

Now you’re pointing at your hard-earned certificate and your private key. You still need to point to that bundle file you created earlier.

Comment out this line by putting # at the start of it:

#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

Right underneath it type:

SSLCertificateChainFile /etc/ssl/certs/yourdomain_com.ca-bundle

Now page down to near the end of the file by hitting ctrl v. Right before the closing /VirtualHost tag, add these lines:

SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'

That line beginning with SSLCipherSuite needs to be all one line so watch out for line breaks if you’re copying and pasting. It’s quite an impressive bit of unintelligible gibberish, isn’t it?

Write out the default-ssl.conf file by hitting ctrl o, followed by enter, and exit this hellish text editor by hitting ctrl x.

Type this (you might need to sudo it):

a2ensite default-ssl.conf

Do the Apache restart dance by typing:

service apache2 reload

You might see a message like “Could not reliably determine the server’s fully qualified domain name…” Don’t worry about it. If, on the other hand, you see an error message that Apache can’t restart, worry about it.

Open your website in a browser; http://yourdomain.com — you should see no difference whatsoever. But now type https://yourdomain.com (but, y’know, swapping out yourdomain.com for your domain). Again, everything should look exactly the same but with one crucial difference: a shiny green lock in the corner of the URL bar indicating that the site is secure.

Redirect http to https

Once you’re happy with the way the https version of your site is working, you can make it the default.

Before doing this, it’s worth making sure that you haven’t hardcoded any images, scripts, or other external files with http:// URLs. If you’re pointing to third-party resources, most of them should also be available over https. Don’t forget that you can use protocol-relative URLS: //fontdeck.com/etc instead of http://fontdeck.com/etc or https://fontdeck.com/etc.

To switch http requests for your site over to https, you’ll need to edit the file that has your port 80 details. That’s probably 000-default.conf in /etc/apache2/sites-available.

Open up that file:

nano /etc/apache2/sites-available/000-default.conf

The top of the file should look something like this:

<VirtualHost *:80>
    ServerAdmin you@yourdomain.com
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www

Again, the details might be slightly different for you: your DocumentRoot might by /var/www/html. Either way, add this line right after that DocumentRoot line:

Redirect / https://yourdomain.com/

(Swapping out yourdomain.com for your domain.)

Do the keyboard shortcut mambo: ctrl o, enter, ctrl x.

Do the Apache restart shuffle:

service apache2 restart

Now try visiting http://yourdomain.com in a browser. You should be automatically redirected to https://yourdomain.com …I really hope it works for you.

Enable HSTS

If you’ve made it this far and everything is working, well done! You have patience and fortitude in equal measure.

Go to ssllabs.com/ssltest and paste in your site’s domain name to see how well your site is doing in the security stakes. You’ll be given a grade, which will bring back all sorts of horrible memories of school tests.

If you’ve been given an A grade, there’s a way to level up to A+. You can enable HTTP Strict Transport Security. No, I don’t understand what it means either.

Go back to the command line on your server. You need to enable the headers module for Apache. Again, you may need to sudo this one:

a2enmod headers

Restart Apache:

service apache2 restart

Now dive back into that default-ssl.conf file:

nano /etc/apache2/sites-available/default-ssl.conf

Hit ctrl v to page down to right before that closing /VirtualHost tag. Add this line right after the gobbledygook you added previously:

Header always set Strict-Transport-Security "max-age=63072000"

You know the drill: ctrl o, enter, ctrl x.

Command Apache to restart before Zod!

service apache2 restart

On ssllabs.com/ssltest hit “clear cache” to test your site again. You should be rewarded with a higher grade and a feeling of smug self-satisfaction. Here’s adactio and here’s Huffduffer.

Troubleshooting

I hope that this walkthrough will be of some use to you. But the chances are that unless you are also using Comodo as your Certificate Authority and you’re running Apache 2.4 on Ubuntu 14, there will be some sort of difference between your setup and mine that could render all of this null and void.

If you run into problems, I probably can’t help you. I’m a complete n00b at this stuff, and if it hadn’t been for Tim’s hand-holding, I doubt I ever would’ve managed.

The https page on the Indie Web Camp is a handy resource that links off to other tutorials.

If you’re serving your site on Cloudfront, Josh’s walkthrough should be very helpful.

If you do make the switch from http to https, please, please, please document each step along the way, and then publish it. There are plenty of articles and blog posts telling us why we need to switch on TLS, but not nearly enough articles and blog posts telling us how.

Saying “You should enable TLS—it’s easy!” can be damaging on two counts:

1. The first part is redundant: we all know that we should be doing this.
2. The second part just makes us feel bad. It’s like telling someone “You should play guitar—it’s easy!” Yeah, it’s easy if you already know how to play guitar.

If you’re a l33t server wizard and you care about this https stuff—which you almost certainly do—I urge you to divert the time and energy you might consider putting into advocacy and instead put that time and effort into helping n00bs like me. If you can gather willing web developers in the same physical space—like Tim did at Indie Web Camp—I think you can achieve maximum knowledge dispersement. (Perhaps Google/Mozilla/Opera/Microsoft dev rels could sponsor TLS days in various cities and towns?)

The issue with https is not that web developers don’t care or understand the importance of security. We care! We understand!

The issue with https is that it’s really bloody hard.

But it’s worth persevering with it.

How to secure your site in an afternoon - Josh Emerson

Josh walks through the process he took to enabling SSL on his site (with particular attention to securing assets on CloudFront).

Throughout the Brighton Digital Festival, Lighthouse Arts will be exhibiting a project from Julian Oliver and Danja Vasiliev called Newstweek. If you’re in town for dConstruct—and you should be—you ought to stop by and check it out.

It’s a mischievous little hardware hack intended for use in places with public WiFi. If you’ve got a Newstweek device, you can alter the content of web pages like, say, BBC News. Cheeky!

There’s one catch though. Newstweek works on http:// domains, not https://. This is exactly the scenario that Jake has been talking about:

SSL is also useful to ensure the data you’re receiving hasn’t been tampered with. It’s not just for user->server stuff

eg, when you visit http://www.theguardian.com/uk , you don’t really know it hasn’t been modified to tell a different story

There’s another good reason for switching to TLS. It would make life harder for GCHQ and the NSA—not impossible, but harder. It’s not a panacea, but it would help make our collectively-held network more secure, as per RFC 7258 from the Internet Engineering Task Force:

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

I’m all for using https:// instead of http:// but there’s a problem. It’s bloody difficult!

If you’re a sysadmin type that lives in the command line, then it’s probably not difficult at all. But for the rest of us mere mortals who just want to publish something on the web, it’s intimidatingly daunting.

Tim Bray says:

It’ll cost you <$100/yr plus a half-hour of server reconfiguration. I don’t see any excuse not to.

…but then, he also thought that anyone who can’t make a syndication feed that’s well-formed XML is an incompetent fool (whereas I ended up creating an entire service to save people from having to make RSS feeds by hand).

Google are now making SSL a ranking factor in their search results, which is their prerogative. If it results in worse search results, other search engines are available. But I don’t think it will have significant impact. Jake again:

if two pages have equal ranking except one is served securely, which do you think should appear first in results?

Ashe Dryden disagrees:

Google will be promoting SSL sites above those without, effectively doing the exact same thing we’re upset about the lack of net neutrality.

I don’t think that’s quite fair: if Google were an ISP slowing down http:// requests, that would be extremely worrying, but tweaking its already-opaque search algorithm isn’t quite the same.

Mind you, I do like this suggestion:

I think if Google is going to penalize you for not having SSL they should become a CA and issue free certs.

I’m more concerned by the discussions at Chrome and Mozilla about flagging up http:// connections as unsafe. While the approach is technically correct, I fear it could have the opposite of its intended effect. With so many sites still served over http://, users would be bombarded with constant messages of unsafe connections. Before long they would develop security blindness in much the same way that we’ve all developed banner-ad blindness.

My main issue—apart from the fact that I personally don’t have the necessary smarts to enable TLS—is related to what Ashe is concerned about:

Businesses and individuals who both know about and can afford to have SSL in place will be ranked above those who don’t/can’t.

I strongly believe that anyone should be able to publish on the web. That’s one of the reasons why I don’t share my fellow developers’ zeal for moving everything to JavaScript; I want anybody—not just programmers—to be able to share what they know. Hence my preference for simpler declarative languages like HTML and CSS (and my belief that they should remain simple and learnable).

It’s already too damn complex to register a domain and host a website. Adding one more roadblock isn’t going to help that situation. Just ask Drew and Rachel what it’s like trying to just make sure that their customers have a version of PHP from this decade.

I want a secure web. I’d really like the web to be https:// only. But until we get there, I really don’t like the thought of the web being divided into the haves and have-nots.

Still…

There is an enormous opportunity here, as John pointed out on a recent episode of The Web Ahead. Getting TLS set up is a pain point for a lot of people, not just me. Where there’s pain, there’s an opportunity to provide a service that removes the pain. Services like Squarespace are already taking the pain out of setting up a website. I’d like to see somebody provide a TLS valet service.

(And before you rush to tell me about the super-easy SSL-setup tutorial you know about, please stop and think about whether it’s actually more like this.)

I’m looking forward to switching my website over to https:// but I’m not going to do it until the potential pain level drops.

For all of you budding entrepreneurs looking for the next big thing to “disrupt”, please consider making your money not from the gold rush itself, but from providing the shovels.