3 ms·
Ah, ok. Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this? That way if someone MITM'd you, you would see that the c
by drdeca 9y ago
Ah, ok.
Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this?
That way if someone MITM'd you, you would see that the cert changed, right?
But I guess if the path you use to the website is always the same, then if they MITM'd you the first time you accessed it, you wouldn't be able to tell?
Hmm, I guess that probably isn't enough then.
Is there really no good way to serve public information from a website that doesn't require periodically updating one's cert, and without risking MITM'ers changing the content?
I guess if the client already has the hash of the content, but that isn't very convenient.
Huh.
I guess example.com needs https then?
- shakna 9y agoThey already serve example.com as both https and http. Try it: https://example.com/ https://example.com/ They don't use HSTS to force it, because example.com isn't meant to anything but an example.
- ams6110 9y ago> Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this? Yes, but browsers make that MUCH more scary than surfing insecure (not https) sites.
- charliesome 9y agoSelf-signed certificates are trivially MITMable. In the absence of cert pinning (like SSH does), they offer no security.
- ams6110 9y agoThe chicken and egg problem with self-signed certs is not solved by Lets Encrypt. It's simply a matter of who do you trust. I can publish my personal CA certificate and ask you to trust it. This is hardly different than how I prove myself to Lets Encrypt.
- tialaramex 9y agoLet's Encrypt has to use one of the Ten Blessed Methods to validate control over the name they issue for. Unlike a random person out on the Internet, doing that validation is their actual job, so they're pretty good at it, and the Ten Blessed Methods tell them what constitutes an acceptable means of doing so. These days Let's Encrypt uses a "multiple view" approach in which more than one physical location in the world hosts Let's Encrypt systems (although only their US West Coast location contains the actual CA) and so they can check that things appear the same from more than one angle, you can't just take over the ISP they're getting service from in California and leverage that to get anything you want. If the views don't agree (e.g. you pass a Let's Encrypt validation from Paris but not from San Francisco) then your application is denied automatically. Now, the next layer above is also interesting. Who checks Let's Encrypt and other public CAs are doing their job? Fortunately Mozilla are on the case again, all major Trust stores say they enforce the Baseline Requirements which explain how a CA should do its job, but all except one make decisions entirely in private. Or maybe they just bin all the complaints if the CA pays them a bribe? Who knows. Mozilla acts openly in public, you can (and indeed your insight might be valuable, so please do) help oversee the Web PKI in their m.d.s.policy group.
- drdeca 9y agoAssuming cert pinning is saving the information from the first time it is accessed, that is sort-of what I was imagining for part of what I was saying.
- CydeWeys 9y agoThe problem with self-signed certs is that you're then given no assurance that you're not being MITMed. An attacker could be stripping the real SSL off a connection, re-encrypting it with a self-signed cert they've created, and then showing that to you. Real SSL certificates have trust chains, which aren't used in self-signed certs.