12 ms·

As long as they treat an untrusted certificate as worse than plaintext (when in fact it's strictly better) this is all theater.

legitster 10y ago
It's better not to pretend to establish trust than establish a fake trust.
- bandrami 10y ago
  Negative. If I'm being phished by organized crime, I'd still rather the NSA not also be able to listen in. The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means.
  - msbarnett 10y ago
    > The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means. All you're doing, then, is attempting to replace a heavily vetted, non-MITMable identity-verification scheme with your own ad-hoc version of the same, and what the security community understands is that you're incredibly likely to fuck this up in a way that makes it trivial for your attacker to forge their identity.
    - bandrami 10y ago
      What nonsense. If I'm on an unsecured wireless network at the local Starbucks, untrusted TLS means I know nobody else in the coffee shop is snooping on it or injecting anything into it. Why is this so difficult for people to grasp?
      - mikeash 10y ago
        Doesn't it just mean that they'd have to MITM you to snoop or inject? It's better, since it raises the bar some, but it doesn't really change what's possible there.
        bandrami 10y ago
        So, we agree: it's strictly better
        jedberg 10y ago
        It's not strictly better -- it gives a false sense of security. As you plainly showed by believing that having https at a Starbucks with an untrusted cert is safe, which it is clearly not. Security involve both a technical and social aspect. While the unsigned cert may offer better security (but there is no way for you to know) it most certainly offers a worse social aspect, that being a false sense of security. So I'd say you're wrong -- it is strictly worse, because it offers no better security but a worse sense of security.
        daxorid 10y ago
        For non-CA certs, you either manually verify hashes or install the self-signed root cert. So no, the attacker would have to at minimum find a SHA1 hash collision, otherwise the client will know they're being MitM'ed.
      - strommen 10y ago
        Untrusted TLS does not mean that nobody else in the coffee shop is snooping on it. That Starbucks access point you've connected to might actually be the Pineapple belonging to the guy at the corner table, and he's injecting his own untrusted SSL certs into your HTTPS traffic and snooping/injecting into all your traffic. EDIT - and to clarify what others have said: HTTPS implies a trusted connection (unlike plain HTTP). And a self-signed certificate cannot be trusted under any circumstances.
        jessaustin 10y ago
    - byuu 10y ago
      Non-MITMable? Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings. Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth. Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.) DNSSEC+DANE would also help, but again, that'd also reduce reliance on the CA system, so don't expect that to ever happen. Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there. "We don't want anyone spying on you! ... unless it's your school, workplace, or laptop vendor (eg Lenovo.)"
      - pfg 10y ago
        > Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings. > Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth. There's a massive difference between "anyone can MitM this connection" and "a small number of nation-state actors might be able to MitM this connection if you do not implement HPKP." A system that prevent such mis-issuance events from staying secret (Certificate Transparency) is also being worked on and is picking up speed. > Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.) AFAIK all browsers except Safari support name constraints. > Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there. This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
- sp332 10y ago
  If the certificate is expired or belongs to a different site, or if the cert chain is clearly broken, then sure, warn the user. But if it just chains to a root you don't recognize, then there's no evidence that anything is really wrong. Just show the page, and use the plain icons (no locks or anything).
  - 80x25 10y ago
    The issue with that approach is that it allows man-in-the-middle attacks, because all of the characteristics you are suggesting the browser validate can be faked if the root is untrusted.
    - bandrami 10y ago
      head against desk BUT PLAINTEXT ALSO ALLOWS THAT, and in addition allows eavesdropping and alteration by another middleman.
      - jcrites 10y ago
        I think you're considering only a single request, and not the larger context of how people interact with systems over time. Imagine that today I visit https://example.com https://example.com and I see a certificate from a CA that I trust. Everything is good: my browser shows a lock icon. Tomorrow (or a year from now), I visit again, and a malicious state actor intercepts the TCP session and returns a certificate that's self-signed or from a CA I don't trust. What should the user experience be? It definitely shouldn't be exactly the same as the trusted cert from example.com! It shouldn't be trusted at all. The behavior where the untrusted certificate shows up as "bad" protects me from MITM -- the difference between trusted and untrusted is the protection. Even though self-signed certs are in some sense better than plaintext, treating them that way will compromise the security of path-validated certs: any degree of trust creates a risk that they'll be substituted for CA-signed certs and trick a user into continuing. In a world where there are only plaintext and self-signed certs, I'd agree that self-signed are better and should be allowed. But in a world with path-validated certs, accepting and trusting self-signed certs has downsides. HSTS helps with this but isn't a complete solution. Your comment would be better without the "bangs head on desk" and caps expressing your frustration. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
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.
msbarnett 10y ago
An untrusted cert is strictly no different than plaintext. Replacing "a plaintext exchange with your attacker" with "an encrypted but unauthenticated exchange with your attacker" is rearranging deckchairs on the Titanic after it's hit the ocean floor
- bandrami 10y ago
  Wrong. You know that no party other than the sender has read or altered the resource in transit. Do you really not see the difference there? I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides. Why people ignore such an obvious point is beyond me.
  - blueplanet200 10y ago
    I think the point is if a cert is suddenly from an untrusted source it's a sign of malicious activity, hence the increased negative feedback to the user relative to an insecure connection. Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
  - mikeash 10y ago
    It can be eavesdropped or altered by MITMing the connection and substituting a different untreated certificate. With trusted certs, you have a reasonably strong assurance that you're talking to the domain owner, even though you may not know who that is.
    - bandrami 10y ago
      Sigh. No. Again: I link to my blog, with HTTPS You have no idea who I am. "Bandrami" is not a meaningful string to you. What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.
JoshTriplett 10y ago
That's exactly what they're fixing: they're working towards marking plaintext as insecure as well.
MrManatee 10y ago
So, how severe should warnings be for untrusted certificates and for plaintext? For untrusted certificates, the answer is clear: very severe. If https://www.facebook.com https://www.facebook.com suddenly has an untrusted certificate, it is almost certainly a case of MITM. The typical end user is not in a position to make an informed decision about trusting it anyway "because it looks right", so the page should just be blocked. In current browsers, bypassing these warnings is very cumbersome. And frankly, making the warnings less conspicuous would be irresponsible. Now, you may argue that plaintext is even worse than an untrusted certificate. But whether we like it or not, in today's internet a browser cannot just block all plaintext connections. Making plaintext warnings as conspicuous as untrusted certificate warnings is unrealistic. That said, there are other steps browsers could take to keep pushing https. Browsers could warn when transmitting passwords unencrypted. And, I don't know if it goes too far, but perhaps browsers could even deprecate persistent cookies for unencrypted connections.

legitster 10y ago

It's better not to pretend to establish trust than establish a fake trust.

bandrami 10y ago
Negative. If I'm being phished by organized crime, I'd still rather the NSA not also be able to listen in. The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means.
- msbarnett 10y ago
  > The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means. All you're doing, then, is attempting to replace a heavily vetted, non-MITMable identity-verification scheme with your own ad-hoc version of the same, and what the security community understands is that you're incredibly likely to fuck this up in a way that makes it trivial for your attacker to forge their identity.
  - bandrami 10y ago
    What nonsense. If I'm on an unsecured wireless network at the local Starbucks, untrusted TLS means I know nobody else in the coffee shop is snooping on it or injecting anything into it. Why is this so difficult for people to grasp?
    - mikeash 10y ago
      Doesn't it just mean that they'd have to MITM you to snoop or inject? It's better, since it raises the bar some, but it doesn't really change what's possible there.
      - bandrami 10y ago
        So, we agree: it's strictly better
        jedberg 10y ago
        It's not strictly better -- it gives a false sense of security. As you plainly showed by believing that having https at a Starbucks with an untrusted cert is safe, which it is clearly not. Security involve both a technical and social aspect. While the unsigned cert may offer better security (but there is no way for you to know) it most certainly offers a worse social aspect, that being a false sense of security. So I'd say you're wrong -- it is strictly worse, because it offers no better security but a worse sense of security.
      - daxorid 10y ago
        For non-CA certs, you either manually verify hashes or install the self-signed root cert. So no, the attacker would have to at minimum find a SHA1 hash collision, otherwise the client will know they're being MitM'ed.
    - strommen 10y ago
      Untrusted TLS does not mean that nobody else in the coffee shop is snooping on it. That Starbucks access point you've connected to might actually be the Pineapple belonging to the guy at the corner table, and he's injecting his own untrusted SSL certs into your HTTPS traffic and snooping/injecting into all your traffic. EDIT - and to clarify what others have said: HTTPS implies a trusted connection (unlike plain HTTP). And a self-signed certificate cannot be trusted under any circumstances.
      - jessaustin 10y ago
  - byuu 10y ago
    Non-MITMable? Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings. Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth. Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.) DNSSEC+DANE would also help, but again, that'd also reduce reliance on the CA system, so don't expect that to ever happen. Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there. "We don't want anyone spying on you! ... unless it's your school, workplace, or laptop vendor (eg Lenovo.)"
    - pfg 10y ago
      > Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings. > Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth. There's a massive difference between "anyone can MitM this connection" and "a small number of nation-state actors might be able to MitM this connection if you do not implement HPKP." A system that prevent such mis-issuance events from staying secret (Certificate Transparency) is also being worked on and is picking up speed. > Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.) AFAIK all browsers except Safari support name constraints. > Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there. This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
sp332 10y ago
If the certificate is expired or belongs to a different site, or if the cert chain is clearly broken, then sure, warn the user. But if it just chains to a root you don't recognize, then there's no evidence that anything is really wrong. Just show the page, and use the plain icons (no locks or anything).
- 80x25 10y ago
  The issue with that approach is that it allows man-in-the-middle attacks, because all of the characteristics you are suggesting the browser validate can be faked if the root is untrusted.
  - bandrami 10y ago
    head against desk BUT PLAINTEXT ALSO ALLOWS THAT, and in addition allows eavesdropping and alteration by another middleman.
    - jcrites 10y ago
      I think you're considering only a single request, and not the larger context of how people interact with systems over time. Imagine that today I visit https://example.com https://example.com and I see a certificate from a CA that I trust. Everything is good: my browser shows a lock icon. Tomorrow (or a year from now), I visit again, and a malicious state actor intercepts the TCP session and returns a certificate that's self-signed or from a CA I don't trust. What should the user experience be? It definitely shouldn't be exactly the same as the trusted cert from example.com! It shouldn't be trusted at all. The behavior where the untrusted certificate shows up as "bad" protects me from MITM -- the difference between trusted and untrusted is the protection. Even though self-signed certs are in some sense better than plaintext, treating them that way will compromise the security of path-validated certs: any degree of trust creates a risk that they'll be substituted for CA-signed certs and trick a user into continuing. In a world where there are only plaintext and self-signed certs, I'd agree that self-signed are better and should be allowed. But in a world with path-validated certs, accepting and trusting self-signed certs has downsides. HSTS helps with this but isn't a complete solution. Your comment would be better without the "bangs head on desk" and caps expressing your frustration. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

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.

msbarnett 10y ago

An untrusted cert is strictly no different than plaintext. Replacing "a plaintext exchange with your attacker" with "an encrypted but unauthenticated exchange with your attacker" is rearranging deckchairs on the Titanic after it's hit the ocean floor

bandrami 10y ago
Wrong. You know that no party other than the sender has read or altered the resource in transit. Do you really not see the difference there? I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides. Why people ignore such an obvious point is beyond me.
- blueplanet200 10y ago
  I think the point is if a cert is suddenly from an untrusted source it's a sign of malicious activity, hence the increased negative feedback to the user relative to an insecure connection. Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
- mikeash 10y ago
  It can be eavesdropped or altered by MITMing the connection and substituting a different untreated certificate. With trusted certs, you have a reasonably strong assurance that you're talking to the domain owner, even though you may not know who that is.
  - bandrami 10y ago
    Sigh. No. Again: I link to my blog, with HTTPS You have no idea who I am. "Bandrami" is not a meaningful string to you. What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.

JoshTriplett 10y ago

That's exactly what they're fixing: they're working towards marking plaintext as insecure as well.

MrManatee 10y ago

So, how severe should warnings be for untrusted certificates and for plaintext? For untrusted certificates, the answer is clear: very severe. If https://www.facebook.com https://www.facebook.com suddenly has an untrusted certificate, it is almost certainly a case of MITM. The typical end user is not in a position to make an informed decision about trusting it anyway "because it looks right", so the page should just be blocked. In current browsers, bypassing these warnings is very cumbersome. And frankly, making the warnings less conspicuous would be irresponsible. Now, you may argue that plaintext is even worse than an untrusted certificate. But whether we like it or not, in today's internet a browser cannot just block all plaintext connections. Making plaintext warnings as conspicuous as untrusted certificate warnings is unrealistic. That said, there are other steps browsers could take to keep pushing https. Browsers could warn when transmitting passwords unencrypted. And, I don't know if it goes too far, but perhaps browsers could even deprecate persistent cookies for unencrypted connections.