4 ms·

> I'd rather everything use SSL That's not going to happen as long as browsers treat the continuum of security like this: BEST: Oh nice, a SSL connection

by avar 16y ago

> I'd rather everything use SSL That's not going to happen as long as browsers treat the continuum of security like this: BEST: Oh nice, a SSL connection with a CA signed cert COOL: A normal HTTP connnection OMGWTFBBQ: ZOMG SOMEONE HAS A SELF SIGNED SSL CERT THE SKY IS FALLING LET'S PRESENT 10 CLICK THROUGH DIALOGS BEFORE THE USER CAN OPEN THE BLODDY SITE As opposed to: BEST: Oh nice, a SSL connection with a CA signed cert COOL: Oh nice, a SSL connection, but no CA signing, treat like HTTP UI-wise COOL: A normal HTTP connection, show the user the traffic isn't encrypted.

tptacek 16y ago
The reason your browser goes "ZOMG" when it sees a self-signed certificate is that there is no way to distinguish the "'avar made himself a handy self-signed certificate" case from the "someone has substituted a random certificate into my Bank of America login". Think about it. Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.
- thorax 16y ago
  That's not strictly true. It doesn't have to be like that. Why can't it be handled like SSH? You can cache the certificate and raise the ZOMG flags when a known site changes behavior. As it is today, browsers scream bloody murder and then require you to store a permanent security exception for the site.
  - tptacek 16y ago
    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.
    - caf 16y ago
      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/ http://cert.startcom.org/ )!
- avar 16y ago
  Yes there is, think about it :) Bank of America has a CA signed cert, so when you go there you display a golden "YOU ARE SECURE, CITIZEN" banner at the top with a lock icon etc. But if someone doesn't have a CA signed SSL cert you treat it no differently than normal HTTP traffic. Then you train users not to submit their financial information to sites that don't have a CA signed SSL certificate (as indicated by the giant "YOU ARE SECURE, CITIZEN" banner). You have to do that anyway, when I go do my online banking I visit a plain http site and then click on my private banking link that takes me to a https site. The easiest way for a MitM to spoof that would be to just direct the user to a plain HTTP site when he goes to do his private banking. So even today users have to understand that they must submit this sort of data over SSL and that the cert involved has to be CA-signed.
  - tptacek 16y ago
    Think harder. How does Firefox know, when it sees a self-signed certificate, that that site wasn't supported to have a certificate signed by a CA? It doesn't, and can't. If the "ZOMG" warning --- which, let's just keep calling it that, because I think it's funny that you think one of the most important pieces of UI in Internet security is a "ZOMG" measure --- didn't exist, attackers could substitute their own "self-signed" certificates for Bank of America's Verisign-signed cert when hijacking www.bankofamerica.com.
    - avar 16y ago
      Yes, it doesn't, and can't. But I'm saying that it doesn't matter. When people visit "foo-bank.com" the easiest way to do a MitM is to simply do a http MitM. Then you don't have to forge any SSL certificates, or rely on the browser not yelling enough. The only way to guard against that is to train users to recognize that they shouldn't be sending money through a non-CA SSL connection, as indicated by their browser with a friendly "Secure" icon somewhere. Thus, if browsers treated non-CA signed SSL connections just like normal HTTP connections, i.e. just used encryption, didn't present any "secure" banners etc. you wouldn't make things any less secure. Non-CA signed SSL traffic is just as secure as unencrypted HTTP traffic (i.e. not), and browsers should treat both of them equivalently.

by avar 16y ago

tptacek 16y ago

The reason your browser goes "ZOMG" when it sees a self-signed certificate is that there is no way to distinguish the "'avar made himself a handy self-signed certificate" case from the "someone has substituted a random certificate into my Bank of America login". Think about it. Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.

thorax 16y ago
That's not strictly true. It doesn't have to be like that. Why can't it be handled like SSH? You can cache the certificate and raise the ZOMG flags when a known site changes behavior. As it is today, browsers scream bloody murder and then require you to store a permanent security exception for the site.
- tptacek 16y ago
  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.
  - caf 16y ago
    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/ http://cert.startcom.org/ )!
avar 16y ago
Yes there is, think about it :) Bank of America has a CA signed cert, so when you go there you display a golden "YOU ARE SECURE, CITIZEN" banner at the top with a lock icon etc. But if someone doesn't have a CA signed SSL cert you treat it no differently than normal HTTP traffic. Then you train users not to submit their financial information to sites that don't have a CA signed SSL certificate (as indicated by the giant "YOU ARE SECURE, CITIZEN" banner). You have to do that anyway, when I go do my online banking I visit a plain http site and then click on my private banking link that takes me to a https site. The easiest way for a MitM to spoof that would be to just direct the user to a plain HTTP site when he goes to do his private banking. So even today users have to understand that they must submit this sort of data over SSL and that the cert involved has to be CA-signed.
- tptacek 16y ago
  Think harder. How does Firefox know, when it sees a self-signed certificate, that that site wasn't supported to have a certificate signed by a CA? It doesn't, and can't. If the "ZOMG" warning --- which, let's just keep calling it that, because I think it's funny that you think one of the most important pieces of UI in Internet security is a "ZOMG" measure --- didn't exist, attackers could substitute their own "self-signed" certificates for Bank of America's Verisign-signed cert when hijacking www.bankofamerica.com.
  - avar 16y ago
    Yes, it doesn't, and can't. But I'm saying that it doesn't matter. When people visit "foo-bank.com" the easiest way to do a MitM is to simply do a http MitM. Then you don't have to forge any SSL certificates, or rely on the browser not yelling enough. The only way to guard against that is to train users to recognize that they shouldn't be sending money through a non-CA SSL connection, as indicated by their browser with a friendly "Secure" icon somewhere. Thus, if browsers treated non-CA signed SSL connections just like normal HTTP connections, i.e. just used encryption, didn't present any "secure" banners etc. you wouldn't make things any less secure. Non-CA signed SSL traffic is just as secure as unencrypted HTTP traffic (i.e. not), and browsers should treat both of them equivalently.