6 ms·

requires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. U

requires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. Unless SSL certificates are suddenly free and trivial to deploy Get the browser vendors to stop being idiots, and treat self-signed SSL connections as identical to plaintext connections. Or even better get them to implement a notary model [ http://perspectives-project.org http://perspectives-project.org ] (as a default rather than an extension), that doesn't allow for a single insecure CA to break the security of the entire web.

revelation 14y ago
I never thought about it from that angle. You are right, it makes no sense for browser vendors to display a big fat warning page because someone signed a certificate himself while they never let you know that 90% of the websites you use are transferred in plain-text over a wholly untrusted network.
- zobzu 14y ago
  Not exactly. The fat warning is there so that you don't get a false sense of security by seeing a little lock. But then again, we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". I wonder how much verisign pays some of us.
  - tptacek 14y ago
    Verisign did not pay Mozilla to make it harder to click through the broken certificate warning.
    - zobzu 14y ago
      Do you mean that you can't bypass the certificate warning anymore in Firefox? (or will not in the near future) If that is so, what is your reasoning behind it?
  - danielweber 14y ago
    we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". wait wait wait what? I am currently in a space where we have to deal with self-signed certificates all the time. I fully accept that people like me will have to deal with more hassles from this so that people don't get their paypal accounts hijacked as easily. But I've yet to find out that I simply cannot connect to a site with a self-signed certificate.
    - zobzu 14y ago
      Have a look at http://www.imperialviolet.org/2012/07/19/hope9talk.html http://www.imperialviolet.org/2012/07/19/hope9talk.html for a glimpse of the future:)
- tptacek 14y ago
  Again: that big fat red warning is the only thing that happens when an attacker hijacks the DNS for Citibank.com at your ISP, redirects traffic to herself, and intercepts all the TLS online banking warnings. Without the big red warning, you might as well not have certificates at all, because nobody would ever notice MITM attacks on TLS. None of the cryptography in TLS works unless users can be assured that every single HTTPS request will generate a big red warning box if the certs don't check out. I absolutely understand how confounding the self-signed certificate warning seems when viewed solely in the context of normal sites operating under normal conditions. But that warning box doesn't mean "this site could be a whole lot safer if it was just configured better!" It means what it says: "you are probably under active attack". Yes, there's a Bayesian problem here: most of the time, you are not actually under attack, and the site operator is in fact just using a poor configuration. But the browser can't know that; it has to assume you're under attack, because there's no other signal available to it to determine otherwise.
  - nowarninglabel 14y ago
    Yeah, except, since as you say, "most of the time, you are not actually under attack", that's exactly what end-users think, and learn to ignore the warning regardless. So, while you may save some tech-savvy users, all your normal users will just click through. I've seen this happen first hand on multiple college campuses with dozens of users where I've been the IT Support/Network Admin. Too many false positives and you end up with security theatre instead of actual protection.
    - tptacek 14y ago
      Which is why the warnings are getting steadily more annoying. What's the alternative? There is no difference on the wire between a self-signed certificate for a site that simply doesn't care about certificates, and a self-signed certificate that is the sole marker of an attacker having hijacked the TLS connection of a site that very much does care about its security. A MITM attack looks identical on the wire to a self-signed cert.
      - 14y ago
zobzu 14y ago
I work for some of the said vendor (and I'm being vague on purpose here). I took part of the discussion. I made the same point you did. People don't care. The argument was quickly dismissed by a "go get a cert for free at startssl". Seriously. I think the Internet is a social change, and transforms people into idiots indeed. People in groups have always been more stupid than single persons. And Internet makes us all one freaking huge group of people. Apparently if you don't share the popular idea you must be destroyed (you'll see this happen often in HN comments too). Otherwise, here's another project, that works on the same principles as perspectives, but has a better back-end (albeit WAY less marketing) IMO http://web.monkeysphere.info/ http://web.monkeysphere.info/
tptacek 14y ago
The first step towards an alternative to the multiple- single- points- of- failure CA model is already underway: it's Trevor Perrin and Moxie Marlinspike's TACK project (currently an Internet Draft). TACK allows sites to cache certificate pins, typically after first contact, so that any site on the Internet can have the same protection that Google's properties have today by virtue of the hardcoded pins in Chrome. As Moxie Marlinspike has said, on HN even, TACK is a sensible and achievable first step towards a substrate that we can build notaries or other trust models on top of. It doesn't require years of study and consideration; it merely extends something that browser vendors already do for their preferred sites. Meanwhile, browsers can't simply treat sites under self-signed certificates as normal plaintext HTTP sites. The user reached the site through an HTTPS URL, which promised them security. When the browser detects and warns about a self-signed certificate, it is telling the user "this site is lying about its security". The simple way to understand this: start by asking what a browser should do when the Citibank Online Banking Login presents a broken cert, and then ask how the browser should know when it's OK for a site to present as merely "not encrypted" (ie, HN login) and when it's not OK (ie, online banking). It can't. The browser has to assume that HTTPS sites with broken certificates are sensitive. Remember also, the "broken certificate" case is exactly what happens when an attacker intercepts a TLS connection for a MITM attack.
- danielweber 14y ago
  What's the status of implementations and/or toolsets for TACK? Can I test it on my clients' SSL websites? Are there settings in any popular webservers for activating TACK? (Oddly, I care least about the browser for this particular question.)
- tbrownaw 14y ago
  Meanwhile, browsers can't simply treat sites under self-signed certificates as normal plaintext HTTP sites. The user reached the site through an HTTPS URL, which promised them security. The user reached the site by clicking on a link or bookmark, and doesn't know or care about http vs https. start by asking what a browser should do when the Citibank Online Banking Login presents a broken cert It should not show the green "Citigroup Inc (US)" at the left of the address bar. If I go type "citicards.com" into the address bar, I end up redirected to a SSL site with an EV cert. If my DNS got hijacked, I would probably end up not redirected to the SSL site, rather than redirected to a site with a broken cert. So non-SSL sites are just as dangerous ad sites with bad certs, and should be presented the same way. how the browser should know when it's OK for a site to present as merely "not encrypted" (ie, HN login) and when it's not OK (ie, online banking). It can't. The browser has to assume that HTTPS sites with broken certificates are sensitive. The browser should visually distinguish sites that are safe for sensitive info from those that are not. Plaintext and self-signed SSL are both not safe. Site with "EV" certs are supposedly safe. Site with other CA-signed certs are also supposedly safe, but slightly less so. So, show EV sites with the green name by the address bar, like recent browsers do now. Show sites with other CA-signed certs with the little lock icon, and maybe color it light green. Show plaintext and self-signed sites with nothing at all, and maybe color the address bar slightly red. But, do this identically for non-signed and self-signed sites.

revelation 14y ago

I never thought about it from that angle. You are right, it makes no sense for browser vendors to display a big fat warning page because someone signed a certificate himself while they never let you know that 90% of the websites you use are transferred in plain-text over a wholly untrusted network.

zobzu 14y ago
Not exactly. The fat warning is there so that you don't get a false sense of security by seeing a little lock. But then again, we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". I wonder how much verisign pays some of us.
- tptacek 14y ago
  Verisign did not pay Mozilla to make it harder to click through the broken certificate warning.
  - zobzu 14y ago
    Do you mean that you can't bypass the certificate warning anymore in Firefox? (or will not in the near future) If that is so, what is your reasoning behind it?
- danielweber 14y ago
  we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". wait wait wait what? I am currently in a space where we have to deal with self-signed certificates all the time. I fully accept that people like me will have to deal with more hassles from this so that people don't get their paypal accounts hijacked as easily. But I've yet to find out that I simply cannot connect to a site with a self-signed certificate.
  - zobzu 14y ago
    Have a look at http://www.imperialviolet.org/2012/07/19/hope9talk.html http://www.imperialviolet.org/2012/07/19/hope9talk.html for a glimpse of the future:)
tptacek 14y ago
Again: that big fat red warning is the only thing that happens when an attacker hijacks the DNS for Citibank.com at your ISP, redirects traffic to herself, and intercepts all the TLS online banking warnings. Without the big red warning, you might as well not have certificates at all, because nobody would ever notice MITM attacks on TLS. None of the cryptography in TLS works unless users can be assured that every single HTTPS request will generate a big red warning box if the certs don't check out. I absolutely understand how confounding the self-signed certificate warning seems when viewed solely in the context of normal sites operating under normal conditions. But that warning box doesn't mean "this site could be a whole lot safer if it was just configured better!" It means what it says: "you are probably under active attack". Yes, there's a Bayesian problem here: most of the time, you are not actually under attack, and the site operator is in fact just using a poor configuration. But the browser can't know that; it has to assume you're under attack, because there's no other signal available to it to determine otherwise.
- nowarninglabel 14y ago
  Yeah, except, since as you say, "most of the time, you are not actually under attack", that's exactly what end-users think, and learn to ignore the warning regardless. So, while you may save some tech-savvy users, all your normal users will just click through. I've seen this happen first hand on multiple college campuses with dozens of users where I've been the IT Support/Network Admin. Too many false positives and you end up with security theatre instead of actual protection.
  - tptacek 14y ago
    Which is why the warnings are getting steadily more annoying. What's the alternative? There is no difference on the wire between a self-signed certificate for a site that simply doesn't care about certificates, and a self-signed certificate that is the sole marker of an attacker having hijacked the TLS connection of a site that very much does care about its security. A MITM attack looks identical on the wire to a self-signed cert.
    - 14y ago

zobzu 14y ago

I work for some of the said vendor (and I'm being vague on purpose here). I took part of the discussion. I made the same point you did. People don't care. The argument was quickly dismissed by a "go get a cert for free at startssl". Seriously. I think the Internet is a social change, and transforms people into idiots indeed. People in groups have always been more stupid than single persons. And Internet makes us all one freaking huge group of people. Apparently if you don't share the popular idea you must be destroyed (you'll see this happen often in HN comments too). Otherwise, here's another project, that works on the same principles as perspectives, but has a better back-end (albeit WAY less marketing) IMO http://web.monkeysphere.info/ http://web.monkeysphere.info/

tptacek 14y ago

The first step towards an alternative to the multiple- single- points- of- failure CA model is already underway: it's Trevor Perrin and Moxie Marlinspike's TACK project (currently an Internet Draft). TACK allows sites to cache certificate pins, typically after first contact, so that any site on the Internet can have the same protection that Google's properties have today by virtue of the hardcoded pins in Chrome. As Moxie Marlinspike has said, on HN even, TACK is a sensible and achievable first step towards a substrate that we can build notaries or other trust models on top of. It doesn't require years of study and consideration; it merely extends something that browser vendors already do for their preferred sites. Meanwhile, browsers can't simply treat sites under self-signed certificates as normal plaintext HTTP sites. The user reached the site through an HTTPS URL, which promised them security. When the browser detects and warns about a self-signed certificate, it is telling the user "this site is lying about its security". The simple way to understand this: start by asking what a browser should do when the Citibank Online Banking Login presents a broken cert, and then ask how the browser should know when it's OK for a site to present as merely "not encrypted" (ie, HN login) and when it's not OK (ie, online banking). It can't. The browser has to assume that HTTPS sites with broken certificates are sensitive. Remember also, the "broken certificate" case is exactly what happens when an attacker intercepts a TLS connection for a MITM attack.

danielweber 14y ago
What's the status of implementations and/or toolsets for TACK? Can I test it on my clients' SSL websites? Are there settings in any popular webservers for activating TACK? (Oddly, I care least about the browser for this particular question.)
tbrownaw 14y ago
Meanwhile, browsers can't simply treat sites under self-signed certificates as normal plaintext HTTP sites. The user reached the site through an HTTPS URL, which promised them security. The user reached the site by clicking on a link or bookmark, and doesn't know or care about http vs https. start by asking what a browser should do when the Citibank Online Banking Login presents a broken cert It should not show the green "Citigroup Inc (US)" at the left of the address bar. If I go type "citicards.com" into the address bar, I end up redirected to a SSL site with an EV cert. If my DNS got hijacked, I would probably end up not redirected to the SSL site, rather than redirected to a site with a broken cert. So non-SSL sites are just as dangerous ad sites with bad certs, and should be presented the same way. how the browser should know when it's OK for a site to present as merely "not encrypted" (ie, HN login) and when it's not OK (ie, online banking). It can't. The browser has to assume that HTTPS sites with broken certificates are sensitive. The browser should visually distinguish sites that are safe for sensitive info from those that are not. Plaintext and self-signed SSL are both not safe. Site with "EV" certs are supposedly safe. Site with other CA-signed certs are also supposedly safe, but slightly less so. So, show EV sites with the green name by the address bar, like recent browsers do now. Show sites with other CA-signed certs with the little lock icon, and maybe color it light green. Show plaintext and self-signed sites with nothing at all, and maybe color the address bar slightly red. But, do this identically for non-signed and self-signed sites.