I recently wondered how long it had been since I added ethitter.com to the Strict Transport Security preload list, as it’s been several years. I added my domain without fully understanding the consequences, though I’ve been fortunate to avoid any problems that could’ve resulted.
Getting back to my original question, version control made it easy to find August 18, 2014 as the date my domain landed in Chromium’s list: https://src.chromium.org/viewvc/chrome?view=revision&revision=290306. At the time, it was one of less than 1,000 domains in the preload list; the bulk of the list was comprised of Google’s own domains. There are currently over 40,000 preloaded domains in Chrome/Chromium. It’s a good thing preloading hasn’t been an issue, it takes a while to get off the list.
After Mozilla’s devastating report, and both Chrome and Firefox’s decision to stop trusting StartSSL certificates issued after October 28, I had no choice but to replace the certificates I’d obtained through StartSSL.
The process took a few months, mainly due to the associated costs. While most of my StartSSL certificates were replaced with ones issued by Let’s Encrypt, there were a few cases where LE wasn’t appropriate. This primarily impacted domains that have many, many subdomains, however there were also a few cases where Let’s Encrypt’s three-month duration would’ve been burdensome. Ultimately I had to purchase three wildcard certificates, plus three single-domain certificates. With those installed, I’m now free of StartSSL/Wosign. After sixty days, I can rotate the pinned keys, impeding any further use of my legacy StartSSL certificates.
Chrome 51 disabled support for NPN, or Next Protocol Negotiation, the mechanism that millions of nginx servers needed to establish HTTP/2 connections with Chrome users. For anyone running nginx compiled against OpenSSL 1.0.1, Chrome 51 users are still connecting over SSL, but only via the legacy HTTP/1.1 specification, which lacks the performance benefits HTTP/2 imparts.
Both the nginx project, and Mattias Geniar, provide lengthier explanations of what changed in Chrome 51:
For those wondering how to restore HTTP/2 support for Chrome 51 users, there is but one answer: switch nginx to OpenSSL 1.0.2. While OpenSSL 1.0.1 is only receiving security updates (and will stop receiving any updates after December 31, 2016), OpenSSL 1.0.2 is actively maintained and receiving new features, including the successor to NPN, which nginx supports: ALPN, or Application-layer Protocol Negotiation.
Continue reading Compiling nginx with OpenSSL 1.0.2 to maintain HTTP/2 support
I really want to love Let’s Encrypt, but then I turn to StartSSL. In my case, I’ve a Class 2 validation, so I can issue wildcard certificates with two-year validity. While Let’s Encrypt is automated, the three-month duration is still an annoyance when different applications and programming languages use different CSR, key, and leaf formats. Add to that the need to enumerate every subdomain covered, and I’m prone to stick with StartSSL.
Also, StartSSL now has an API, which was one advantage of Let’s Encrypt. While I don’t issue certificates frequently enough to warrant such an integration, it’s a nice feature to consider for other StartSSL applications.
For me, it comes down to this: I use Let’s Encrypt for the fluctuating, random assortment of domains that I register on a whim and redirect elsewhere, while StartSSL is what I use for domains of permanence or significance. This isn’t a slight against Let’s Encrypt, it just doesn’t suit my particular needs.
For some time now, I’ve hoped to disable support for TLSv1 and TLSv1.1, and move to Mozilla’s “modern” cipher suite. Unfortunately, due to one application not supporting this combination of protocols and ciphers, I’ve been unable to make the switch.
Continue reading One
ssl_protocols to rule them all
Lately, I’ve explored creating my own CSRs for use with Let’s Encrypt, so I can control the common name and subject names. I’m neurotic enough that I can’t bear to let Let’s Encrypt decide.
Continue reading Generating a CSR with SAN at the command line
As part of today’s admin track at WordCamp San Diego, I delivered a talk titled “Getting Started with SSL.” My intent was to demystify the terminology and process involved with securely delivering traffic. I described my talk this way:
Revelations like Edward Snowden’s about NSA spying, and Google’s announcement that it will begin considering a site’s HTTPS status in its rankings, led to a lot of talk about moving websites to secure connections. Similarly, the rise in ecommerce, and the simplicity with which one can accept payments online, has increased the need for sites to be available securely. With so much terminology that’s likely new, often very similar, and rarely more than a stream of initialisms, this entire discussion can be very intimidating. I’ll clarify basic terminology, offer some reasons why it’s worthwhile to secure a site whenever possible, and share several solutions to cover everything from simple to enterprise needs.
While securing a site can be intimidating at first, the recent introduction of Let’s Encrypt (https://letsencrypt.org/) significantly simplifies the process for most sites. Many hosts have introduced support for this service, which I’ll discuss before delving into options for sites and circumstances that aren’t suited to Let’s Encrypt.
Continue reading Getting Started with SSL–WordCamp San Diego 2016
I’ve been experimenting lately with Let’s Encrypt for SSL certificates, contemplating whether it can replace my StartSSL Class 2 wildcards.
For those unfamiliar with Let’s Encrypt, it’s a free certificate authority aimed at simplifying the process of making a site available via a secure connection. If you’re reading this on ethitter.com, your browser’s address bar will display a lock icon, the text https, or some other indicator that the connection is secure.
Until Let’s Encrypt launched its public beta in December 2015, acquiring a certificate involved many steps; at times, considerable cost; and terminology many find confusing. Let’s Encrypt intends to address these issues, and effectively does so in at least one way.
Continue reading Automatically renewing a lot of Let’s Encrypt certificates
When you’re ready to ensure that no one visits your site over an insecure connection, the Strict Transport Security header is key.
Continue reading Ensuring encrypted web traffic with Strict Transport Security headers (HSTS)
In the course of continually updating my various services’ configurations, I crave external verification that I haven’t broken everything.
Continue reading External tools for checking my configurations