4 ms·
It would be OK if browsers treated self-signed certificates a little better. There are lots of contexts where a self-signed, long or non-expiring certificate ma
by zmmmmm 2y ago
It would be OK if browsers treated self-signed certificates a little better. There are lots of contexts where a self-signed, long or non-expiring certificate makes perfect sense. But browsers and security stacks in general react as if the whole application is broken, just because they didn't see the certificate before - even when they have no evidence the certificate is malicious. SSH does it nicely, with a prompt on first use and then detecting tampering after - why has this not been adopted for TLS?
- appendix-rock 2y agoOpenSSH does it “nicely” for you maybe. I’ll maybe even accept “for most users of an SSH client”. This behaviour implemented in a browser is utterly unacceptable. The average user is orders of magnitude less technically capable. You are not the only user of the software that you use.
- gruez 2y agoHow does this work when a user is visiting https://bank.example https://bank.example for the first time? Are we supposed to let granny eat the risk of a MITM when she gets a new device? Furthermore, how is such a system supposed to work in private browsing? You either have to introduce a fingerprinting vector (by which certificates are remembered/trusted), or expose users to MITM risk every time.
- zmmmmm 2y agoI'm not proposing this for everything and high security public facing contexts can definitely do the maintenance to manage frequent certificate rotation. I just don't want my garage door integration with my car to stop working because its certificate broke. I'd argue these privately deployed single use dedicated certificates are actually better off self-signed and issued on a TOFU basis than using public key infrastructure. It's how bluetooth and many other things work, so why on earth are browsers so bent against it.
- ziml77 2y agoTOFU is a pretty bad trust model. Even with SSH you're supposed to validate the fingerprint with some already known trusted source. Otherwise you're just assuming that the first time you connect you aren't being MITMed.
- Spivak 2y agoIn fact the recommended way to do SSH fingerprint checks is with a CA.
- greyface- 2y agoCAs don't make this problem go away; they just shift it to a central "trusted" party. With the CA model, we're assuming that Let's Encrypt isn't being MITMed.
- foul 2y agoAlso we assume no MITM when updating the ca-cert thing on OSes.
- ndsipa_pomu 2y agoIf you want to use self-signed certificates, just load it into the relevant browsers as a trusted cert. Of course, there's issues if you want the general public to just trust a certificate that could have been generated by anyone and possibly fall for a MITM attack.