7 ms·

Regardless of your views of the CA system, trusted certificate issued by a CA are designed to offer both security and authentication. An untrusted certificate h

by consto 10y ago

Regardless of your views of the CA system, trusted certificate issued by a CA are designed to offer both security and authentication. An untrusted certificate however provides only security. I expect the reason browsers treat unsigned certificates as bad is for a few major reasons: * Security without authentication (While slightly better than plain HTTP) is near useless in the real world. Without the authentication that CA trusted certificates provide, you have no guarantee that the host you are communicating with is the site and not a MitM attacker, all the certificate stops is passive eavesdropping. * The SSH system of connecting to a host once and saving the certificate is unworkable on the larger web. You do not and can not know the certificate of any random site you visit, the CA system solves this problem. * Browser vendors and CAs actively want websites to be using CA trusted certificates. If browsers accepted untrusted certificates a larger number of sites would use them, as opposed to CA trusted certificates. * Unlike HTTP, a minuscule number of websites use unsigned certificates and as a result it is safe to penalise sites using them. The end game for browsers vendors is that every site uses a CA trusted certificate; this update to chrome further shows their intent to deprecate HTTP.

dlubarov 10y ago
I agree that TLS has little value if you can't verify who you're talking to. But at the very least, it's no worse than unencrypted HTTP. So it doesn't make sense to me that browsers are more stern about untrusted certs.
- deadbunny 10y ago
  It's treated as worse because if people get used to clicking "accept" for self signed then they'll do the same when they get MITM'd. Want an example? Any error dialogue.
  - Dylan16807 10y ago
    So you think the current browser behavior, with a scary warning and an accept button, is bad? If they were treated like http there would be no dialogue.
- catdog 10y ago
  It still protects from passive wiretapping which is strictly better than no encryption at all. It's a shame browsers are treating it way worse.
- TazeTSchnitzel 10y ago
  Not quite. If you are given an HTTPS link, you should expect security. Passive upgrade from HTTP to HTTPS would be a different thing.
  - dlubarov 10y ago
    Fair point - if the browser is displaying the protocol in the URL bar that is. I believe Edge and Safari don't. Chrome and Firefox seem to display https:// https:// but not http:// http://. In the case of Chrome visiting an untrusted CA, it already displays https:// https:// in red with strikethrough, which seems like a perfectly adequate way to negate any expectation of security. So the scary warning which takes two clicks to pass seems like overkill. If I was making a browser, I'd just show a "secure" symbol for valid, trusted certs, an "insecure" symbol for anything else, and no protocols in the URL bar.
byuu 10y ago
If only we had a secure DNS system (let's hypothetically call it "DNSSEC"), where you could put your certificate hashes into a TLS record (to make up a name for it, how about "DANE"?) ... but surely if such a thing existed, and for several years at that, browsers would support it, right?
- tptacek 10y ago
  They would support it. Very briefly. They would quickly discover that it doesn't work well in practice, simply due to spotty DNS connectivity for end systems, and so every TLS site would need certificates anyways, and DNSSEC+DANE would just end up being another set of CAs. Then they would remove support from the browser. It's easy to predict a future that's already happened! Fun fact: if you have a .COM name, guess who becomes your de facto CA in an all DNSSEC+DANE world? You guessed it: Verisign!
  - byuu 10y ago
    I'm aware of your opposition to DNSSEC+DANE from previous posts here. Like others, I'll agree it's not perfect. Nothing is. Verizon may sign the .com TLD, but that's fine: there are lots of registration providers that offer free DNSSEC support for you (eg gkg.net). Once you have that, you can convey your certificate hash securely, and thus you no longer have to pay some racketeering jackass company $100-600 a year just to get "*.yourdomain.com" in the common name field. The current reality with DNS is that it's the wild west. All this emphasis on security and yet a DNS provider is entirely unencrypted and hijackable by anyone to send you to an alternate domain. If you haven't visited the domain before, even HSTS/HPKP won't help you.
    - tptacek 10y ago
      The problem isn't that you have to pay to get DNSSEC signatures. The problem is that you have to trust the same entities as you did before, PLUS a bunch of new ones. Why are we beating around the bush with this? DNSSEC is, on its face, a key escrow scheme. Why would we even consider adopting it?

by consto 10y ago

dlubarov 10y ago

I agree that TLS has little value if you can't verify who you're talking to. But at the very least, it's no worse than unencrypted HTTP. So it doesn't make sense to me that browsers are more stern about untrusted certs.

deadbunny 10y ago
It's treated as worse because if people get used to clicking "accept" for self signed then they'll do the same when they get MITM'd. Want an example? Any error dialogue.
- Dylan16807 10y ago
  So you think the current browser behavior, with a scary warning and an accept button, is bad? If they were treated like http there would be no dialogue.
catdog 10y ago
It still protects from passive wiretapping which is strictly better than no encryption at all. It's a shame browsers are treating it way worse.
TazeTSchnitzel 10y ago
Not quite. If you are given an HTTPS link, you should expect security. Passive upgrade from HTTP to HTTPS would be a different thing.
- dlubarov 10y ago
  Fair point - if the browser is displaying the protocol in the URL bar that is. I believe Edge and Safari don't. Chrome and Firefox seem to display https:// https:// but not http:// http://. In the case of Chrome visiting an untrusted CA, it already displays https:// https:// in red with strikethrough, which seems like a perfectly adequate way to negate any expectation of security. So the scary warning which takes two clicks to pass seems like overkill. If I was making a browser, I'd just show a "secure" symbol for valid, trusted certs, an "insecure" symbol for anything else, and no protocols in the URL bar.

byuu 10y ago

If only we had a secure DNS system (let's hypothetically call it "DNSSEC"), where you could put your certificate hashes into a TLS record (to make up a name for it, how about "DANE"?) ... but surely if such a thing existed, and for several years at that, browsers would support it, right?

tptacek 10y ago
They would support it. Very briefly. They would quickly discover that it doesn't work well in practice, simply due to spotty DNS connectivity for end systems, and so every TLS site would need certificates anyways, and DNSSEC+DANE would just end up being another set of CAs. Then they would remove support from the browser. It's easy to predict a future that's already happened! Fun fact: if you have a .COM name, guess who becomes your de facto CA in an all DNSSEC+DANE world? You guessed it: Verisign!
- byuu 10y ago
  I'm aware of your opposition to DNSSEC+DANE from previous posts here. Like others, I'll agree it's not perfect. Nothing is. Verizon may sign the .com TLD, but that's fine: there are lots of registration providers that offer free DNSSEC support for you (eg gkg.net). Once you have that, you can convey your certificate hash securely, and thus you no longer have to pay some racketeering jackass company $100-600 a year just to get "*.yourdomain.com" in the common name field. The current reality with DNS is that it's the wild west. All this emphasis on security and yet a DNS provider is entirely unencrypted and hijackable by anyone to send you to an alternate domain. If you haven't visited the domain before, even HSTS/HPKP won't help you.
  - tptacek 10y ago
    The problem isn't that you have to pay to get DNSSEC signatures. The problem is that you have to trust the same entities as you did before, PLUS a bunch of new ones. Why are we beating around the bush with this? DNSSEC is, on its face, a key escrow scheme. Why would we even consider adopting it?