6 ms·

> 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

> 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
    A self-signed certificate can be trusted when my client recognizes it as one that I already trust. E.g., maybe it's for a server in my home, to which I have previously connected via my wired home network.
- byuu 10y ago
  This part is wrong, sorry. An attacker can sign his own certificate for your domain, and send you that. Then he can communicate with the real site on your behalf. Your only protection would be if you pre-installed said self-signed certificate before going to the coffee shop. Your warning would be that the certificate was suddenly untrusted again. It also wouldn't prevent an attack by someone that could forge a certificate from a trusted intermediate CA. HPKP could help there; but if you have someone like that targeting you in a coffee shop, you have much bigger problems. The important thing though is that this is still not worse than plain HTTP. And in fact, it's better: it makes the attacker's job a lot more difficult. Especially when done at large scale (eg ISP ad injection.)
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.

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
  A self-signed certificate can be trusted when my client recognizes it as one that I already trust. E.g., maybe it's for a server in my home, to which I have previously connected via my wired home network.
byuu 10y ago
This part is wrong, sorry. An attacker can sign his own certificate for your domain, and send you that. Then he can communicate with the real site on your behalf. Your only protection would be if you pre-installed said self-signed certificate before going to the coffee shop. Your warning would be that the certificate was suddenly untrusted again. It also wouldn't prevent an attack by someone that could forge a certificate from a trusted intermediate CA. HPKP could help there; but if you have someone like that targeting you in a coffee shop, you have much bigger problems. The important thing though is that this is still not worse than plain HTTP. And in fact, it's better: it makes the attacker's job a lot more difficult. Especially when done at large scale (eg ISP ad injection.)

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.