5 ms·

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 t

by mholt 8y ago

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. 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.) 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 (cough Caddy). Of course, securing one's system to prevent break-ins is paramount. 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. 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 (cough 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: https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomment-2336055 https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomm... and https://caddyserver.com/blog/certificate-management-policies https://caddyserver.com/blog/certificate-management-policies -- 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. 4. Key rotation: Again, I know of only one web server that does this by default and automatically (cough Caddy). 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: https://github.com/mholt/caddy/pull/2274 https://github.com/mholt/caddy/pull/2274 (And even if a misissuance is identified, what is one to do about it?) 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.) (Note: I am the author of the Caddy web server.)

Intermernet 8y ago
Thanks Matt, I love Caddy and use it for most of my sites. It's a real example of "it just works".
tialaramex 8y ago
For 2. note that Let's Encrypt just automates a facility every CA provides (is required to provide). A compliant CA is required to have a means by which you can point out that a private key is revealed and they'll revoke certificates for the corresponding public key. It's just that for Let's Encrypt this is automated the same way as everything else. You SHOULD NOT post private keys, if you find a key that you think shouldn't have been shown to you, you can prove you have it without posting it anywhere. That's what Let's Encrypt does in the revoke-with-key modality. A poor man's way to do this with tools a typical Linux system has is to construct a CSR using that private key, but requesting a Subject that makes it obvious this is a bogus request, e.g. CN="mholt should not have this private key" instead of any real subject. Bad guys don't learn the private key by seeing this CSR, but everyone (who understands cryptography) learns that you must have the private key or moral equivalent. The requirement to revoke if a private key is revealed is why that craziness with the reseller happened earlier this year where they'd been keeping all their customer keys in escrow (if you allowed them to generate the key - never do this) and they said "Oh, these keys are leaked" and sent all the keys to the Certificate Authority. The CA went "Oh, these really are the private keys, huh" and revoked all the affected certificates. The Baseline Requirements don't have an option for "But, but, my reseller is an idiot, pretend you haven't seen the keys". So, don't trust your idiot reseller with your keys and then they can't do that to you.
- danillonunes 8y ago
  One note regarding revocations. Recently a bank in Brazil got leaked the private key for its main domain (and internet banking frontend). The leaker tried to ransom the bank but wasn’t happy, so he went to the press with a detailed report of what he got, and included a message signed with the bank’s key as a proof. The bank denied everything. But the more interesting thing was that, when confronted about the key, they said it was indeed legit, but their site was already using a new certificate for a while, so everything is ok. And part of the press bought it, including sites targeted to technical audiences. That’s how much a lot of people in real world don’t know exactly how PKI works. It took a few weeks until the leaked cert was finally revoked. And now I wonder if it was really the bank who did it.

by mholt 8y ago

Intermernet 8y ago

Thanks Matt, I love Caddy and use it for most of my sites. It's a real example of "it just works".

tialaramex 8y ago

For 2. note that Let's Encrypt just automates a facility every CA provides (is required to provide). A compliant CA is required to have a means by which you can point out that a private key is revealed and they'll revoke certificates for the corresponding public key. It's just that for Let's Encrypt this is automated the same way as everything else. You SHOULD NOT post private keys, if you find a key that you think shouldn't have been shown to you, you can prove you have it without posting it anywhere. That's what Let's Encrypt does in the revoke-with-key modality. A poor man's way to do this with tools a typical Linux system has is to construct a CSR using that private key, but requesting a Subject that makes it obvious this is a bogus request, e.g. CN="mholt should not have this private key" instead of any real subject. Bad guys don't learn the private key by seeing this CSR, but everyone (who understands cryptography) learns that you must have the private key or moral equivalent. The requirement to revoke if a private key is revealed is why that craziness with the reseller happened earlier this year where they'd been keeping all their customer keys in escrow (if you allowed them to generate the key - never do this) and they said "Oh, these keys are leaked" and sent all the keys to the Certificate Authority. The CA went "Oh, these really are the private keys, huh" and revoked all the affected certificates. The Baseline Requirements don't have an option for "But, but, my reseller is an idiot, pretend you haven't seen the keys". So, don't trust your idiot reseller with your keys and then they can't do that to you.

danillonunes 8y ago
One note regarding revocations. Recently a bank in Brazil got leaked the private key for its main domain (and internet banking frontend). The leaker tried to ransom the bank but wasn’t happy, so he went to the press with a detailed report of what he got, and included a message signed with the bank’s key as a proof. The bank denied everything. But the more interesting thing was that, when confronted about the key, they said it was indeed legit, but their site was already using a new certificate for a while, so everything is ok. And part of the press bought it, including sites targeted to technical audiences. That’s how much a lot of people in real world don’t know exactly how PKI works. It took a few weeks until the leaked cert was finally revoked. And now I wonder if it was really the bank who did it.