Making LetsEncrypt work with HPKP and leaf-pinning

Note: I no longer use key pinning and support for the feature is deprecated in Chrome. Proceed at your own risk.

Public key pinning is scary. The technology’s purpose is to allow website owners to include a cryptographic fingerprint in outgoing HTTP headers that corresponds with the fingerprint of the server’s certificate; if the fingerprint in the headers doesn’t match the actual fingerprint, it could be evidence that something nefarious is going on. You might be the victim of a MITM attack, or the site might have been compromised, or you might be accessing a fake version of the site that has a legitimate (but falsely-issued) SSL/TLS certificate.

The scary part is that as with HSTS, a mistake with your HPKP configuration can make your site unreachable—potentially for a long time.

Read more

Finally moving to LetsEncrypt with HAProxy, Varnish, and Nginx

Poor StartCom. Since 2009—ever since I read Glenn Fleishman’s Ars piece on how to get free SSL/TLS certificates—StartCom has been my go-to for certs. Most welcome has been StartCom’s pricing on wildcard certs (that is, certificates for *.yourdomain.com, allowing you to use a single certificate for everything, if you desire) While other certificate authorities charge rigoddamndiculous prices for individual wildcard certs, StartCom gives you unlimited wildcard certs for the price of a single $60 identity validation (yes, you read that correctly). It has always been and remains an unbeatable deal. Literally. No one else comes close. Buying wildcard certs w/StartCom felt like I’d discovered an Internet cheat code.

Then a Chinese company called WoSign bought StartCom and started doing shady stuff—including, most egregiously, issuing and backdating certificates to try to circumvent the upcoming mass SHA-1 deprecation. The response has been swift and devastating: WoSign and StartCom’s certs will become untrusted by major web browsers (details on exactly what that means can be read here).

Which means, after eight years, I needed to find a new CA. And with how heavily I’ve leaned on wildcard certs, it wasn’t looking good.

Read more

A working Varnish 4 config for WordPress 4.4

Adapting my extremely crufty Varnish 3.x config to Varnish 4 took most of a weekend. I found a great VCL3-to-4 script on github that did a lot of the heavy lifting, but there were a lot of little things to chase down and fix; the VCL syntax between versions 3 and 4 is juuuust different enough to cause headaches. One of the major stumbling blocks was adapting the WordPress configuration that I’d been using forever and ever; it turns out that revisiting it was a really good idea, because I’m a lot happier with WordPress VCL now than I was before.

Read more

WordPress, Varnish, Jetpack, and SSL/HSTS

If you’re self-hosting WordPress on the HAProxy + Varnish + Nginx stack we’ve long talked about here at BigDino, you might have run into a few configuration quirks during set-up that went outside the scope of our blog entries a bit. One of those quirks is getting WordPress working with Jetpack, a WordPress plugin by the WordPress folks that adds a whole dump truck’s worth of extra management features and functionality to self-hosted WordPress.

Read more

HTTPS and HSTS with Varnish, thanks to HAProxy

(Now updated to work with HAProxy 1.6.x!)

The unencrypted web is on the way out. We made the switch here at BigDino Central to all-HTTPS a few weeks ago, but doing so brought with it a problem: how can we keep using Varnish cache with HTTPS traffic? The answer turned out to be by adding another layer into the web stack—and now we’re using HAProxy to terminate SSL. It wasn’t difficult to set up, and it works for all the different sites we host on our one physical web server.

Keeping Varnish in the mix felt important, because we’ve been using it for a few years (wow, has it been that long?), and it’s a neat tool that’s helped the site bear up under some crazy Reddit- and Ars-driven traffic storms. But the nature of Varnish means that out of the box it won’t help you with HTTPS traffic. Because the HTTPS negotiation happens between the end user and Nginx—which sits below Varnish in the stack—all Varnish sees of HTTPS traffic is the encrypted side, and you can’t cache what looks like an unending string of unique, encrypted nonsense.

Read more

Why leave Octopress for Ghost?

More than one person has e-mailed me in the past few months asking why I switched away from Octopress—which I was initially so excited about!—to Ghost. Octopress, after all, has a lot of attractive qualities—it can live on Github (though I’ve never bothered with that functionality); you can write blog posts in vim; it uses static pages rather than requiring PHP or Node or something running behind the scenes to generate stuff.

After a year of semi-regular blogging with Octopress, though, I was just kind of…bored with it. The official Octopress blog hasn’t received an update since July 2011, only a few months before I actually started using Octopress myself. Blogging with vim and banging out a static site and pushing it via rsync was cool, but ultimately it just wasn’t as convenient as I’d wanted it to be, and the longer I went between blog entries, the more of Octopress/Jekyll’s liquid tags I’d have to go look up again.

And so…Ghost.

Read more

Custom Twitter URL shortening and image uploading

I don’t know what normal people do on days off from work, but I do things that are too esoteric even to write about for Ars Technica because…because I think there’s something wrong with me. So, last Friday I spent a few hours setting up a vanity URL shortening service and custom image uploading service for Twitter, so I can, I don’t know, be cooler than everyone else. It was surprisingly fun!

First, though, the annoying caveat: Twitter already shortens every link with its t.co service, and you can’t opt out. The reasons they give are mostly marginal and downplay the fact that aggregate clicking behavior has a substantial dollar value attached to it, but there you go. Still, it’s totally cool to have your own link shortening—you just get to have your links double-shorted when they’re posted inside of tweets.

Link shortening works best with a cool short domain, and I desperately wanted bigdi.no as mine. Unfortunately, to register a domain in the .no TLD requires an actual business presence in Norway, so that was out. I settled on registering bigsaur.us instead, which is only two letters longer.

Read more

Working on a new comment system

This is an old post. It may contain broken links and outdated information.

In the previous post, I walked through setting up Discourse, a Ruby-based web forum. I’m in the process of shifting this blog’s comment system from Disqus, which I’ve never been wholly comfortable with, over to using Discourse instead. There is being done via a plug-in for Octopress currently under development by one of the posters over at the main Discourse development forum.

Read more

Setting up Discourse with Passenger and Nginx

This is an old post. It may contain broken links and outdated information.

Hi there, visitors from Google! The procedure outlined here will work to get Discourse up and running, but you are way, way better off following the official Discourse installation guide and utilizing the Discourse Docker image. Proceed below at your own risk!

I like fiddling with new software and seeing if I can make it work—that’s what most of this blog is about, in fact. Most of the web-based apps I’ve walked through deploying have been written with PHP, but there’s a fancy new bit of Ruby-based forum software that I’ve sort of fallen in love with: Discourse.

Discourse is shiny and new, and the developers (including Jeff Atwood, one of the folks behing StackExchange). It’s made out of Ruby instead of PHP, and it uses PostgreSQL and Redis for its back-end. The project is still very, very beta; there are multiple methods of deploying it and it has a robust development environment that you can set up and start hacking away on.

This doesn’t matter much to me, though—I dont’ code. I just wanted to set it up and play with it. So, this is a walkthrough on how to deploy Discourse on Ubuntu, using Nginx and Phusion Passenger. If you want to see the end result, check out my Discourse test forum—when we’re done, you’ll have something similar up and running.

Read more

Node.js, Redis, and Etherpad

This is an old post. It may contain broken links and outdated information.

Etherpad Lite is a real-time collaborative text editor which allows multiple users to simultaneously fiddle with a document. Everyone can see everyone else’s changes in real time, which is really cool. The “lite” tag after the name is there because the Etherpad Lite project was spawned from the ashes of the original Etherpad project, which itself was snapped up by Google and transformed into the ill-fated Google Wave. Wave was never really all that popular and has since been killed, but the core idea is still totally cool—to present a document to more than one user and have all users be able to make changes to it, and to have those changes shown to all other users as they’re made. It’s a surprisingly complex problem to solve. For one thing, it’s entirely possible that more than one user can change the same thing at the same time; there has to be a way of telling who “wins” and whose changes are tossed out. Even more complex is figuring out a way to track all the changes and organize them, and then display them for everyone.

The original Etherpad project solved this with a full mix of heavy web technologies, requiring you to install Java, Scala, and MySQL; it utilized no small amount of server resources and was difficult to scale. Etherpad Lite jettisons a lot of its predecessor’s bulk and does things in a much more web two-point-oh fashion. Specifically, Etherpad Lite runs on Node.js, a server-side Javascript engine which can be used for lots and lots of fancy things—Node is really deserving of its own blog entry, and we’re using only a tiny subset of its features here. Etherpad Lite also needs a database to hold the documents and store changes; out of the box it can use MySQL, but in this post we’re going to take things even further and configure it to run on Redis, an extremely fast memory-based key-value store. Finally, we’ll do a tiny bit of hacking on Etherpad’s HTML to force it to display a list of all the “pads” (documents) currently in its database.

Read more