Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is strictly true that in the HTTPS security model, there is no difference between a self-signed certificate and a forged certificate. The browser can't know which sites are supposed to have real certs and which are supposed to have fake ones. Secure channel protocols are tricky, and this is one of the reasons why.

You propose key continuity as a (drastic) extension to the HTTPS security model. I'm ambivalent about key continuity. It sort of works with SSH, but also used to be one of the more often-exploited weaknesses with that protocol, before we entered an 8-year span where memory corruption flaws in sshd were an even easier way to mess with it.

Key continuity works when you have long-term relationships between clients and servers. It doesn't work, at all, when multiple people share machines (as at kiosks), or when people change machines or reinstall. Also, unlike cookies, which gracefully repopulate themselves when you clean them up, the "HTTPS key continuity" model requires you to store certificates, for every website you ever talk to and every site those sites depend on, forever.

Instead of the (I think kind of hacky) key continuity idea, browsers should just come up with a way to allow users to opt-in easily to new CA's.

Meanwhile, it's pretty annoying when people talk as if the Firefox bogus-certificate UI is an affront to everyone's intelligence. No, without that dialog, HTTPS wouldn't work.



It's because all these self-taught PHP developers think it's some kind of affront to have to pay $25 for a CA-signed certificate for their shopping cart application.

Even though you can now get CA-signed certificates for free ( eg http://cert.startcom.org/ )!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: