HTTPS in the real world
Hmm, went into this article skeptical, but came out agreeing with it more than I expected. Makes some excellent points, and highlights some real challenges of the ecosystem.<p>But actually, I'm optimistic about Web security in general. Especially with regards to HTTPS, things have improved a lot, and looks like they will continue to get better! We really have come a long way in a few years to baking privacy into the Internet. In general, nowadays attackers will have to be well-funded, have a lot of time on their hands, and/or focus on specific targets to break this encryption. (Aside from the usual side-channels, 0-days, etc., which exist, but which is also a different problem.)<p>1. Private keys staying private: there was a catastrophic flaw in web servers a few years ago called Heartbleed that handed out the private keys like candy. These flaws are rare, and modern web servers written in memory-safe languages are much more immune to such vulnerabilities (<i>cough</i> Caddy). Of course, securing one's system to prevent break-ins is paramount.<p>2. Revocation: It's still mostly broken, because it's generally not enforced, and when it is, that can take days. Recent research that I believe has yet to be published proposes a way to scale CRLs at the regional or organizational level with 99.99+% cache hit rate. Fun fact: with Let's Encrypt, you can revoke anyone's certificate... if you have their private key. Another fun fact: revocation is really, really, really not awesome when it's used as a censorship weapon.<p>3. OCSP: Again, I agree with the article here. Vanilla OCSP is not awesome. OCSP stapling, however, is actually pretty awesome! But only if done right. Unfortunately, only one web server does it "right" out-of-the-box (<i>cough</i> Caddy). OCSP stapling is broken enough in most mainstream web servers that I would generally advice against using them with Must-Staple certificates. More details: <a href="https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomment-2336055" rel="nofollow">https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomm...</a> and <a href="https://caddyserver.com/blog/certificate-management-policies" rel="nofollow">https://caddyserver.com/blog/certificate-management-policies</a> -- basically, OCSP stapling is great when web servers implement it robustly and conservatively, and when it doesn't require any configuration. Highly recommended in that case.<p>4. Key rotation: Again, I know of only one web server that does this by default and automatically (<i>cough</i> Caddy).<p>5. Certificate transparency: As of now, there is not enough useful consumption of CT logs. We have TBs of data but no one to read them. So, we're close to integrating a CT monitor into Caddy so that your web server can report if it finds a certificate issued for a name it is serving that it did not request: <a href="https://github.com/mholt/caddy/pull/2274" rel="nofollow">https://github.com/mholt/caddy/pull/2274</a> (And even if a misissuance is identified, what is one to do about it?)<p>I want to emphasize that just because PKI is not a totally solved problem does not mean that every site should not be using HTTPS. Surely this will be controversial (even though, in my mind, it is not a question), but I'm going to sleep for the night so I won't be able to answer right now. (And I'll pre-empt the argument that HTTPS, or at least DV certs, are bad because it makes phishing sites look safe: that's not why PKI was invented. I'll go out on a limb and suggest that even phishing sites deserve HTTPS... not because of the merits of the site, but for the sake of the poor victim.)<p>(Note: I am the author of the Caddy web server.)