Tag: Let’s Encrypt

Posted on
by

The cost of implementing HTTPS on your own site is a lot lower now than it used to be. For instance:

  • Let’s Encrypt offers free certificates for any site, and some web hosts have software integration that make ordering, verifying and installing a certificate as simple as checking a box and clicking a button. (I’m impressed with DreamHost. I turned on secure hosting for some of my smaller sites a few months ago by just clicking a checkbox. It generated and installed the certs within minutes, and it’s been renewing them automatically ever since.)
  • Amazon now has a certificate manager you can use for CloudFront and other AWS services that’s free (as long as you don’t need static IP addresses, anyway) and only takes a few minutes to set up.
  • CloudFlare is offering universal HTTPS even on its free tier. You still need a cert to encrypt the connection between your site and CloudFlare to do it properly, but they offer their own free certs for that. They’ll also let you use a self-signed certificate on the back end if you want. (It’s still not perfect because it’s end-to-Cloudfront-to-End instead of end-to-end, but it’s better than plaintext.)

You may not need a unique IP address anymore. Server Name Indication (SNI) enables HTTPS to work with multiple sites on the same IP address, and support is finally widespread enough to use in most cases. (Unless you need to support IE6 on Windows XP, or really old Android devices.)

Now, if you want the certificate to validate your business/organization, or need compatibility with older systems, you may still want to buy a certificate from a commercial provider. (The free options above only validate whether you control the domain.) And depending on your host, or your chosen software stack if you’re running your own server, you may still have to go through the process of generating a request, buying the cert and going through the validation process, and installing the cert.

But if all you want to do is make sure that your data, and your users’ data, can’t be intercepted or altered in transit when connecting to reasonably modern (2010+) software and devices, it’s a lot less pain than it was even a year ago.

The hard part: Updating all your old links and embedded content. (This is why I’m still working on converting Speed Force and the rest of hyperborea.org in my spare time, though this blog is finally 100% HTTPS.)

And of course dealing with third-party sources. If you connect to someone else’s site, or to an appliance that you don’t control, you have to convince them to update. That can certainly be a challenge.

Expanded from a comment on Apple: iOS to Require HTTPS for Apps by January at Naked Security.

Posted on
by

I finally moved the public side of this blog over to HTTPS last weekend. Traditionally I’ve preferred to put public info on HTTP and save HTTPS for things that need it – passwords, payment info, login tokens, anything that should be kept private — but between the movement to protect more and more of the web from eavesdropping and the fact that tools are making it harder to split content between open and encrypted sides (the WordPress app sometimes gets confused when you run the admin over HTTPS but keep the public blog on HTTP), I decided it was time.

The last sticking point was putting HTTPS on my CDN, and I’d decided to try getting Let’s Encrypt and CloudFront working together over the weekend. Then Amazon announced their Certificate Manager for AWS, which took care of the hard part. All I had to do was request and approve the (domain-validated) certificate, then attach it. Done!

Downside: Because I opted for the SNI option on the CDN, rather than pay the premium to get unique IP addresses on every CloudFront endpoint, the images won’t work with older browsers like IE6. (Server Name Indication is a way to put more than one HTTPS site on the same IP address.)

On the other hand, the cert I have on the site itself is SHA2-signed (as it should be, now that SHA-1 is no longer sufficient), so it wouldn’t work with older browsers even if I turned off the CDN and kept the images on the server.

It’s the first time I’ve actually broken the ability of older browsers to see any of my personal sites. I’ve broken layouts, sure, but not completely cut them off. In general I’d rather not, but I think I’m OK with it this time because

  1. SHA1 really does have to go, SHA2 is well-established, and it’s not like I’m providing downloads of modern browsers or a critical communications forum for people who are stuck with ancient hardware/software because that’s all that’s available to them.
  2. SNI has been around for TEN YEARS.

And as it turns out, DreamHost’s ModSecurity rules block IE6 to begin with, so the whole site’s already broken in that browser.

So I guess next time I redesign I can finally drop any IE6 workarounds. :shrug: