4 ms·

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 wit

by 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.
  - tptacek 16y ago
    This is why your bank doesn't let you make withdrawals from your account on port 80. You need to keep re-reading this sentence: there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't. It can't tell the difference. "But that untrusted connection is no less secure than an HTTP connection!", you retort. Wrong. The HTTP connection isn't lying to you about how secure it is. The HTTPS connection with the bogus cert is, as far as Firefox is concerned, lying. And for most users, most of the time, it's right. Something is wrong with the connection. I understand that it drives you nuts that there is collateral damage to this security warning. Yes. There is collateral damage. You get a very noisy exception dialog even when you wanted a self-signed cert. But the alternative to that dialog allows attackers to spoof Citibank, and the browser vendors have all decided that your self-signed cert is less important than Citibank.
    - avar 16y ago
      > This is why your bank doesn't let you make withdrawals from your account on port 80. It doesn't matter that my bank doesn't allow withdrawals on port 80 as long as a MitM allows that, and you can't guard against that unless you train users to expect CA-signed SSL sites for things like that. > You need to keep re-reading [...] I've already read that and replied to it at: http://news.ycombinator.com/item?id=1609818 http://news.ycombinator.com/item?id=1609818 > The HTTP connection isn't lying to you about how secure it is. A non-CA HTTPS connection isn't lying to me, it's purely a matter of implementation how you treat that sort of thing. You seem to think that certification and encryption are inseparable, they aren't. You can have SSL encryption presuming that you're talking to a known-good party, while also having the ability to initiate connections to CA-signed parties. > [...] There is collateral damage. Yes, but there's no need for it. Browers can decide how they present SSL, if they consistently present a big "You're secure" banner when talking to CA+SSL sites and users get used to that when transferring money they'll spot that something's up when it's missing.
    - seabee 16y ago
      How many people look at the 'https' part rather than the padlocks or large green bars telling you it's secure? I can count the number of those people on one hand.
othermaciej 16y ago
There's a few problems with your hypothetical, from the browser implementor point of view: 1) "Then you train users..." -- if your security mechanism relies on this you have already failed. 2) In the attack case, the user would have to look for the absence of an indicator. It's very hard to notice absence of an indicator as a sign of danger, especially if there are are many normal situations where it's fine for the indicator to not be there. Imagine this design for a car engine warning light: - Normally it's always off. - Whenever you turn left, it goes on if everything is fine. - However, if your engine needs service, then when you turn left, the warning light stays off. Do you think this would do a good job of alerting people to engine trouble? Your suggestion is the same thing. It's hard to train yourself to notice the lock icon not appearing, even if you are very security-aware (which most users are not). 3) If the user has a bookmark, Top Sites/Speed Dial page, or URL autocomplete entry for the SSL URL to their bank, it's hard to redirect them to vanilla HTTP. So in fact, silently accepting self-signed certs creates more MITM opportunity. 4) Srict Transport Security will likely close the remaining gaps in #3 (e.g. typing the domain name in a fresh browser instance) over time.

by avar 16y ago

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.
- tptacek 16y ago
  This is why your bank doesn't let you make withdrawals from your account on port 80. You need to keep re-reading this sentence: there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't. It can't tell the difference. "But that untrusted connection is no less secure than an HTTP connection!", you retort. Wrong. The HTTP connection isn't lying to you about how secure it is. The HTTPS connection with the bogus cert is, as far as Firefox is concerned, lying. And for most users, most of the time, it's right. Something is wrong with the connection. I understand that it drives you nuts that there is collateral damage to this security warning. Yes. There is collateral damage. You get a very noisy exception dialog even when you wanted a self-signed cert. But the alternative to that dialog allows attackers to spoof Citibank, and the browser vendors have all decided that your self-signed cert is less important than Citibank.
  - avar 16y ago
    > This is why your bank doesn't let you make withdrawals from your account on port 80. It doesn't matter that my bank doesn't allow withdrawals on port 80 as long as a MitM allows that, and you can't guard against that unless you train users to expect CA-signed SSL sites for things like that. > You need to keep re-reading [...] I've already read that and replied to it at: http://news.ycombinator.com/item?id=1609818 http://news.ycombinator.com/item?id=1609818 > The HTTP connection isn't lying to you about how secure it is. A non-CA HTTPS connection isn't lying to me, it's purely a matter of implementation how you treat that sort of thing. You seem to think that certification and encryption are inseparable, they aren't. You can have SSL encryption presuming that you're talking to a known-good party, while also having the ability to initiate connections to CA-signed parties. > [...] There is collateral damage. Yes, but there's no need for it. Browers can decide how they present SSL, if they consistently present a big "You're secure" banner when talking to CA+SSL sites and users get used to that when transferring money they'll spot that something's up when it's missing.
  - seabee 16y ago
    How many people look at the 'https' part rather than the padlocks or large green bars telling you it's secure? I can count the number of those people on one hand.

othermaciej 16y ago

There's a few problems with your hypothetical, from the browser implementor point of view: 1) "Then you train users..." -- if your security mechanism relies on this you have already failed. 2) In the attack case, the user would have to look for the absence of an indicator. It's very hard to notice absence of an indicator as a sign of danger, especially if there are are many normal situations where it's fine for the indicator to not be there. Imagine this design for a car engine warning light: - Normally it's always off. - Whenever you turn left, it goes on if everything is fine. - However, if your engine needs service, then when you turn left, the warning light stays off. Do you think this would do a good job of alerting people to engine trouble? Your suggestion is the same thing. It's hard to train yourself to notice the lock icon not appearing, even if you are very security-aware (which most users are not). 3) If the user has a bookmark, Top Sites/Speed Dial page, or URL autocomplete entry for the SSL URL to their bank, it's hard to redirect them to vanilla HTTP. So in fact, silently accepting self-signed certs creates more MITM opportunity. 4) Srict Transport Security will likely close the remaining gaps in #3 (e.g. typing the domain name in a fresh browser instance) over time.