7 ms·

> The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost. (S

by jlebar 12y ago

> The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost. (Secrecy means that only you and the other party can decode what is being communicated. Privacy is secrecy with an identified or authenticated other party.) I'm frustrated to read this myth being propagated. We should know better. In the presence of only passive network attackers, sure, self-signed certs buy you something. But we know that the Internet is chock-full of powerful active attackers. It's not just NSA/GHCQ, but any ISP, including Comcast, Gogo, Starbucks, and a random network set up by a wardriver that your phone happened to auto-connect to. A self-signed cert buys you nothing unless you trust every party in the middle not to alter your traffic [1]. If you can't know whom you're talking to, the fact that your communications are private to you and that other party is useless. I totally agree that the CA system has its flaws -- maybe you'll say that it's no better in practice than using self-signed certs, and you might be right -- but my point is that unauthenticated encryption is not useful as a widespread practice on the web. Browser vendors got this one right. [1] Unless you pin the cert, I suppose, and then the only opportunity to MITM you is your first connection to the server. But then either you can never change the cert, which is a non-option, or otherwise users will occasionally have to click through a scary warning like what ssh gives. Users will just click yes, and indeed that's the right thing to do in 99% of cases, but now your encryption scheme is worthless. Also, securing first connections is useful.

phkamp 12y ago
self-signed-certs is about making NSA&friends work for it, rather than giving them a free ride. Today they can grep plaintext as they want. With SSC's they would have to pinpoint what communication they really need to see. That would be a major and totally free improvement in privacy for everybody. As for why the browsers so consistently treat SSC's as ebola: I'm pretty sure NSA made that happen -- they would be stupid not to do so.
- deleted 12y ago
  [deleted]
- jlebar 12y ago
  Given that one can get a CA-signed certificate for free, and that in any case the cost of a cert is dwarfed by the cost of running a nontrivial website, I think you overestimate the number of sites which would be "secured" in this manner and the gains to be had. But the important point is what we'd lose: If a UA accepts a SSC for an arbitrary website, then the NSA can actively MITM a website that uses a CA cert -- the browser will never see that CA cert, so it doesn't know better. The only way around this would be to accept SSCs but treat them as no different from plain HTTP in the UI. But now websites have no incentive to use the certs in the first place, further limiting the benefits to be had. Really, just buy a certificate. It's not that hard. > That would be a major and totally free improvement in privacy for everybody. Tangentially, I feel like you're trying to have it both ways in arguing for more encryption on the web and also against mandatory encryption on the grounds of energy efficiency. SSCs wouldn't be "totally free" under your model -- we'd be spending carbon on it. I might argue that if one is going to pollute to encrypt their data, it would be unethically wasteful to use a SSC, which comes at exactly the same environmental cost as a CA cert but offers much weaker guarantees.
  - TazeTSchnitzel 12y ago
    > The only way around this would be to accept SSCs but treat them as no different from plain HTTP in the UI. But now websites have no incentive to use the certs in the first place, further limiting the benefits to be had. That, or make HTTP/2's non-secure mode always be encrypted. Which is what people like myself would like. Opportunistic encryption at zero hassle and with zero security problems.
    - jlebar 12y ago
      If it were a foregone conclusion that HTTP/2 would have a non-secure mode, I'd agree, yes. But in practice HTTP/2 isn't going to have a non-secure mode in most browsers. Maybe you're arguing that it would be better to have an insecure but encrypted mode in all browsers? Could be, but I don't think so. As it is, if a site wants the benefits of HTTP/2, they have to establish actually secure communication (inasmuch as CAs provide that). It seems good to me to use the performance benefits of HTTP/2 as a carrot to accomplish real encryption everywhere. If the costs of getting a cert were too high, then maybe this would leave many websites stuck on HTTP/1, which would be worse than having those sites use an encrypted-but-insecure mode in HTTP/2, but I don't think that will be the case.
djcapelis 12y ago
Yes, pinning the cert, (i.e. TOFU - Trust On First Use) is exactly the right way to treat self signed certificates and under that model they offer real security. The idea that you can't do anything with self signed certs and nothing makes them okay is a much more troublesome untruth, IMO. Rejecting self-signed certs and only allowing users to use the broken CA PKI model is the wrong choice. Browsers didn't get it right. The CA model is broken, is actually being used to decrypt people's traffic and though your browser might pin a couple big sites, won't protect the rest very well by default. It's a bad hack and we should fix the underlying issue with the PKI. I believe moxie was right, a combination of perspectives + TOFU is the way to do this. Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH.
- jlebar 12y ago
  I'm not defending the CA model; there are lots of known problems. But using a CA-signed cert before pinning it is way better than blindly trusting whatever cert you get on your first connection, which is the OP's suggestion wrt SSCs. > Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH. When was the last time you verified a certificate's fingerprint out of band when connecting to a server for the first time? Maybe you're the kind of person who scrupulously does this, but in my experience even paranoid computer types don't, to say nothing of regular people. > I believe moxie was right, a combination of perspectives + TOFU is the way to do this. +1, it's hard to go wrong listening to Moxie.
- drzaiusapelord 12y ago
  >TOFU - Trust On First Use The scenarios where this works are pretty limited. Pretty much only a server you set up. Jane User has no idea if the first use of ecommercesite.com is actually safe. You generally do because you have other band access to that server to see the key or key fingerprint. Even that can be thwarted by a clever MITM attack. >Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH. Yeah, that's generally for system administrative access not general public access for the web. For that kind of access, you need higher safeguards, thus the CA system we have today.

by jlebar 12y ago

phkamp 12y ago

self-signed-certs is about making NSA&friends work for it, rather than giving them a free ride. Today they can grep plaintext as they want. With SSC's they would have to pinpoint what communication they really need to see. That would be a major and totally free improvement in privacy for everybody. As for why the browsers so consistently treat SSC's as ebola: I'm pretty sure NSA made that happen -- they would be stupid not to do so.

deleted 12y ago
[deleted]
jlebar 12y ago
Given that one can get a CA-signed certificate for free, and that in any case the cost of a cert is dwarfed by the cost of running a nontrivial website, I think you overestimate the number of sites which would be "secured" in this manner and the gains to be had. But the important point is what we'd lose: If a UA accepts a SSC for an arbitrary website, then the NSA can actively MITM a website that uses a CA cert -- the browser will never see that CA cert, so it doesn't know better. The only way around this would be to accept SSCs but treat them as no different from plain HTTP in the UI. But now websites have no incentive to use the certs in the first place, further limiting the benefits to be had. Really, just buy a certificate. It's not that hard. > That would be a major and totally free improvement in privacy for everybody. Tangentially, I feel like you're trying to have it both ways in arguing for more encryption on the web and also against mandatory encryption on the grounds of energy efficiency. SSCs wouldn't be "totally free" under your model -- we'd be spending carbon on it. I might argue that if one is going to pollute to encrypt their data, it would be unethically wasteful to use a SSC, which comes at exactly the same environmental cost as a CA cert but offers much weaker guarantees.
- TazeTSchnitzel 12y ago
  > The only way around this would be to accept SSCs but treat them as no different from plain HTTP in the UI. But now websites have no incentive to use the certs in the first place, further limiting the benefits to be had. That, or make HTTP/2's non-secure mode always be encrypted. Which is what people like myself would like. Opportunistic encryption at zero hassle and with zero security problems.
  - jlebar 12y ago
    If it were a foregone conclusion that HTTP/2 would have a non-secure mode, I'd agree, yes. But in practice HTTP/2 isn't going to have a non-secure mode in most browsers. Maybe you're arguing that it would be better to have an insecure but encrypted mode in all browsers? Could be, but I don't think so. As it is, if a site wants the benefits of HTTP/2, they have to establish actually secure communication (inasmuch as CAs provide that). It seems good to me to use the performance benefits of HTTP/2 as a carrot to accomplish real encryption everywhere. If the costs of getting a cert were too high, then maybe this would leave many websites stuck on HTTP/1, which would be worse than having those sites use an encrypted-but-insecure mode in HTTP/2, but I don't think that will be the case.

djcapelis 12y ago

Yes, pinning the cert, (i.e. TOFU - Trust On First Use) is exactly the right way to treat self signed certificates and under that model they offer real security. The idea that you can't do anything with self signed certs and nothing makes them okay is a much more troublesome untruth, IMO. Rejecting self-signed certs and only allowing users to use the broken CA PKI model is the wrong choice. Browsers didn't get it right. The CA model is broken, is actually being used to decrypt people's traffic and though your browser might pin a couple big sites, won't protect the rest very well by default. It's a bad hack and we should fix the underlying issue with the PKI. I believe moxie was right, a combination of perspectives + TOFU is the way to do this. Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH.

jlebar 12y ago
I'm not defending the CA model; there are lots of known problems. But using a CA-signed cert before pinning it is way better than blindly trusting whatever cert you get on your first connection, which is the OP's suggestion wrt SSCs. > Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH. When was the last time you verified a certificate's fingerprint out of band when connecting to a server for the first time? Maybe you're the kind of person who scrupulously does this, but in my experience even paranoid computer types don't, to say nothing of regular people. > I believe moxie was right, a combination of perspectives + TOFU is the way to do this. +1, it's hard to go wrong listening to Moxie.
drzaiusapelord 12y ago
>TOFU - Trust On First Use The scenarios where this works are pretty limited. Pretty much only a server you set up. Jane User has no idea if the first use of ecommercesite.com is actually safe. You generally do because you have other band access to that server to see the key or key fingerprint. Even that can be thwarted by a clever MITM attack. >Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH. Yeah, that's generally for system administrative access not general public access for the web. For that kind of access, you need higher safeguards, thus the CA system we have today.