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&#x27;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&#x2F;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&#x27;s system to prevent break-ins is paramount.<p>2. Revocation: It&#x27;s still mostly broken, because it&#x27;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&#x27;s Encrypt, you can revoke anyone&#x27;s certificate... if you have their private key. Another fun fact: revocation is really, really, really not awesome when it&#x27;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 &quot;right&quot; 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:&#x2F;&#x2F;gist.github.com&#x2F;sleevi&#x2F;5efe9ef98961ecfb4da8#gistcomment-2336055" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;sleevi&#x2F;5efe9ef98961ecfb4da8#gistcomm...</a> and <a href="https:&#x2F;&#x2F;caddyserver.com&#x2F;blog&#x2F;certificate-management-policies" rel="nofollow">https:&#x2F;&#x2F;caddyserver.com&#x2F;blog&#x2F;certificate-management-policies</a> -- basically, OCSP stapling is great when web servers implement it robustly and conservatively, and when it doesn&#x27;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&#x27;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:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;pull&#x2F;2274" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;pull&#x2F;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&#x27;m going to sleep for the night so I won&#x27;t be able to answer right now. (And I&#x27;ll pre-empt the argument that HTTPS, or at least DV certs, are bad because it makes phishing sites look safe: that&#x27;s not why PKI was invented. I&#x27;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.)