5 ms·

The problem with achieving real adoption of crypto had historically been made a lot harder than it should be because too many problems are trying to be solved a

by pdkl95 12y ago

The problem with achieving real adoption of crypto had historically been made a lot harder than it should be because too many problems are trying to be solved at the same time. Separate the problems! It is much easier to find realistic solutions when the requirements are narrower. The remaining needs can be solved later on. Once some usable infrastructure has been established, it might be possible to leverage that infrastructure to add back in some of the missing features. For HTTPS, a good start would be PHK's suggestion of simply auto-generating self-signed certs in apache by default, as a replacement for plaintext. Authenticating those certs can happen later. After keys are everywhere, a potential solution might be t o allow both PKI authorities and some sort of web-of-trust (or other methods? blockchain? something new?), and exposing the source of trust to the user in way they can manage. There is no one-size-fits-all solution to the trust problem, so let the user decide because they know what their requirements are. If I'm browsing to some bank, a well-known PKI root might be a good trust source. If I'm chatting on some local forum, a web-of-trust auth might be better (it's a local forum, so fingerprints can be exchanged manually, friend-to-friend).

tptacek 12y ago
Encryption is not separable from authentication.
- tbrownaw 12y ago
  Right. Because active MITM attacks -- at least if limited to cases where the attacker doesn't know how / if the connection is authenticated -- carry zero risk of alerting those being attacked.
  - tptacek 12y ago
    The thing that alerts you to MITM attacks is authentication!
    - tbrownaw 12y ago
      I am aware of that. An untargetted attacker cannot know that there is no authentication. Dragnetting connections where they don't recognize any authentication therefore risks detection. That risk to the attacker is not present when observing plaintext connections. . I'm not safe from muggers because I have eyes in the back of my head to see them trying to sneak up on me. I'm (largely) safe because someone else is likely to see them (or catch them on camera) and get them caught.
    - pdkl95 12y ago
      One of the ways to detect MitM is authentication. It is a particularly good method, which I recommend whenever possible, but it is not the only method. Suspicious changes in the environment might be another, as would detecting data that leak past the middleman. Key pinning would be an example of a change in the environment, unexpected changes in important network topology or routing could be another. An example of a leaking middleman might be detection of the real (non-poisoned) "duplicate" packet in a DNS-poisoning packet race. These methods are nowhere near as good as proper authentication, of course. Reliability of detection is probably very low. The point is that it is better than the case of sending plaintext that anybody can trivially wiretap with zero chance of detection[1]. As always, it is important to define your threat model. If you are defending against any kind of targeted attack, then yes, authentication is a firm requirement. If your threat model is only concerned with avoiding the trivial surveillance that can be done in bulk, anything that forces the opponent to use a more complicated ("expensive") MitM attack is a success. [1] modulo any still-very-hypothetical quantum communication methods. We can reevaluate our options if those technologies ever work well enough for common use,
      - tptacek 12y ago
        Key pinning is authentication; it's the same authentication system SSH uses: key continuity.
- CHY872 12y ago
  It so is. A plain old Diffie Hellman key exchange will give you encryption without authentication. All you need for encryption is to be able to share a secret - this in no way requires authentication.
  - ctz 12y ago
    I have a secret. I want to share this secret with only my best friend. I do this by telling the secret to everybody I meet, whether they look like my friend or not. Eventually I meet my friend, and tell them too. This is confidentiality without authenticity. It is an incoherent idea.
    - tptacek 12y ago
      It's incoherent at a high level, and it stays incoherent as you delve deeper into the theory. For instance, systems that lack authentication tend to lose confidentiality to error oracles.
  - apendleton 12y ago
    Without authentication your connection is susceptible to undetectable man-in-the-middle attacks that DHE does nothing to prevent. That they're separable is superficially true, but not interesting, as encryption alone doesn't stop people from reading your traffic, which is the whole point.
    - pdkl95 12y ago
      This argument comes up so regularly, one might speculate that some people are trying to keep the internet in plaintext[1]. Yet again, encryption is a replacement for plantext, which is the only thing it should be compared to. Of course you can MitM attack it, but that's not something that is easily done in bulk. Simple encryption raises the cost of an attack from "trivial wiretaps, DPI optional" to the time, money, and effort required to do a targeted MitM attack. Additionally, while it is generally impossible to detect wiretaps, MitM can leak information that betrays the presence of an attack. Remember, this isn't intended to stop all types of attacks. It is simply a very easy to implement feature that lets you replace plaintext with something resistant (not proof) to eavesdropping in general, and proof against some types of bulk surveillance. Note: I haven't said anything about presenting this type of non-authenticated communication to the user as "secure". [1] see PHK's "Operation Orchestra" talk
- unethical_ban 12y ago
  There are middle grounds that would still be better than a plaintext internet. Cert pinning, even self-signed certs, would be better. First time to https://example.com https://example.com - I get a prompt and a UI element telling me it's self signed. I accept the risk (This may not be who you think it is! - but it probably is) 2 - nth time to https://example.com https://example.com - UI element tells me it's self signed, but the same as before. Whether it's the NSA or the site, it's the same person at the other end. Next - does the cert change to a PKI-trusted? Then great! I get a UI element (no prompt) showing the site is trusted. Does the site get a new self-signed cert? Back to the first step. I believe this, and the parent notion of default cert generation by apache installs, is better than no SSL. It's not as good as fully verifiable auth. --- And son of a gun, I know this isn't an original idea, but I can't believe it took another post to remind me this is exactly how SSH works. Sure, you can get the server key to your DO host and transfer it to your client, but how many people do that? They accept the fingerprint they see at first, assume it's good, and probably raise an eyebrow if it changes. Don't like it? OK, let's go back to telnet.
  - MichaelGG 12y ago
    If state level actors wanted to MITM all SSH connections to make you accept the wrong key, they could. But it has a high chance of being caught as generally, you'll pay attention when the key changes. Plus you can reasonably verify the key out of band. (And one could imagine an extension to add a bit of CA-style key verification, like, "was this key generated by my account or my VPS provider, allowing you to manually verify one key and then being set for the rest.) Whereas if you do this on HTTP, a: you're constantly having a lot more "first time" connections. B: you've got no real way to know when the key changed legitimately. Users would quickly grow accustomed to key change warnings and ignore them. Or you'd see banners on sites like "ignore the key warning; I reinstalled my blog and the key changed". Attacks could even inject such a banner. If you want to manually verify every cert, you can already do that today: just go and add certs to your browser! Unauthed HTTPS-by-default just adds complexity and a false sense of security and isn't worth pushing out on the public.
    - deleted 12y ago
      [deleted]
- MichaelGG 12y ago
  Sure, but at least it means simple optical splitters can no longer read the contents of your web traffic. That's arguably not worth a whole lot, and may trick people into feeling safer when they shouldn't. But if nothing else changed (no browser indications, etc), wouldn't using DH on all HTTP be strictly better than nothing? Theoretically. In practice, I suppose entities just replace their splitters with a retransmitter and we're back to zero.
- fryguy 12y ago
  Encryption without authentication solves a majority of threat vectors that would allow people to look at your private communication. (authentication here means knowing that key K belongs to some organization, not authenticated encryption). If, by default, everything was encrypted, then the internet would be a much better place. Once encryption is in place, it means that active monitoring will be easy to detect because if only a small number of people actually verify that the remote party is who they say they are, then it will still be detected.
  - tptacek 12y ago
    No, it doesn't. It stops a majority of primitive exploits. Breaking exploits is not the same thing as closing vulnerabilities.
- 101914 12y ago
  Is this meant to be a general statement or just a response to some comment? One thing I do not like about the popular "strong" encryption solutions are that they are tied to relatively "weak" authentication solutions. Instead of two programs that each do one thing, we are instructed to use one program that does two things. I prefer that encryption and authentication were are viewed as distinct programs. If desired they can be used together. Sometimes we may not wish to rely on the hope of an "encrypted channel", but instead we might just want to send an encrypted blob over an untrusted channel (=the internet). Obviously it makes sense to send your encrypted blob to the correct destination, but that does not mean you _must_ use encryption to verify the destination is the correct one; it is an option, but not the only one. For example, it is possible to do the authentication part via some old-fashioned method that does not require the internet.
- hobarrera 12y ago
  Of course it is. It prevents passive eavesdropping, but is useless against active attackers. In the end, it's of little use, but that doesn't mean you can separate both things.
fleitz 12y ago
Yup, let's not let perfect become the enemy of good. SSH works basically this way, certs are autogenerated, the client records the key, and lets you know if it changes. And doesn't everyone recommend SSH over Telnet, despite certs mostly (never?) not being signed?

by pdkl95 12y ago

tptacek 12y ago

Encryption is not separable from authentication.

tbrownaw 12y ago
Right. Because active MITM attacks -- at least if limited to cases where the attacker doesn't know how / if the connection is authenticated -- carry zero risk of alerting those being attacked.
- tptacek 12y ago
  The thing that alerts you to MITM attacks is authentication!
  - tbrownaw 12y ago
    I am aware of that. An untargetted attacker cannot know that there is no authentication. Dragnetting connections where they don't recognize any authentication therefore risks detection. That risk to the attacker is not present when observing plaintext connections. . I'm not safe from muggers because I have eyes in the back of my head to see them trying to sneak up on me. I'm (largely) safe because someone else is likely to see them (or catch them on camera) and get them caught.
  - pdkl95 12y ago
    One of the ways to detect MitM is authentication. It is a particularly good method, which I recommend whenever possible, but it is not the only method. Suspicious changes in the environment might be another, as would detecting data that leak past the middleman. Key pinning would be an example of a change in the environment, unexpected changes in important network topology or routing could be another. An example of a leaking middleman might be detection of the real (non-poisoned) "duplicate" packet in a DNS-poisoning packet race. These methods are nowhere near as good as proper authentication, of course. Reliability of detection is probably very low. The point is that it is better than the case of sending plaintext that anybody can trivially wiretap with zero chance of detection[1]. As always, it is important to define your threat model. If you are defending against any kind of targeted attack, then yes, authentication is a firm requirement. If your threat model is only concerned with avoiding the trivial surveillance that can be done in bulk, anything that forces the opponent to use a more complicated ("expensive") MitM attack is a success. [1] modulo any still-very-hypothetical quantum communication methods. We can reevaluate our options if those technologies ever work well enough for common use,
    - tptacek 12y ago
      Key pinning is authentication; it's the same authentication system SSH uses: key continuity.
CHY872 12y ago
It so is. A plain old Diffie Hellman key exchange will give you encryption without authentication. All you need for encryption is to be able to share a secret - this in no way requires authentication.
- ctz 12y ago
  I have a secret. I want to share this secret with only my best friend. I do this by telling the secret to everybody I meet, whether they look like my friend or not. Eventually I meet my friend, and tell them too. This is confidentiality without authenticity. It is an incoherent idea.
  - tptacek 12y ago
    It's incoherent at a high level, and it stays incoherent as you delve deeper into the theory. For instance, systems that lack authentication tend to lose confidentiality to error oracles.
- apendleton 12y ago
  Without authentication your connection is susceptible to undetectable man-in-the-middle attacks that DHE does nothing to prevent. That they're separable is superficially true, but not interesting, as encryption alone doesn't stop people from reading your traffic, which is the whole point.
  - pdkl95 12y ago
    This argument comes up so regularly, one might speculate that some people are trying to keep the internet in plaintext[1]. Yet again, encryption is a replacement for plantext, which is the only thing it should be compared to. Of course you can MitM attack it, but that's not something that is easily done in bulk. Simple encryption raises the cost of an attack from "trivial wiretaps, DPI optional" to the time, money, and effort required to do a targeted MitM attack. Additionally, while it is generally impossible to detect wiretaps, MitM can leak information that betrays the presence of an attack. Remember, this isn't intended to stop all types of attacks. It is simply a very easy to implement feature that lets you replace plaintext with something resistant (not proof) to eavesdropping in general, and proof against some types of bulk surveillance. Note: I haven't said anything about presenting this type of non-authenticated communication to the user as "secure". [1] see PHK's "Operation Orchestra" talk
unethical_ban 12y ago
There are middle grounds that would still be better than a plaintext internet. Cert pinning, even self-signed certs, would be better. First time to https://example.com https://example.com - I get a prompt and a UI element telling me it's self signed. I accept the risk (This may not be who you think it is! - but it probably is) 2 - nth time to https://example.com https://example.com - UI element tells me it's self signed, but the same as before. Whether it's the NSA or the site, it's the same person at the other end. Next - does the cert change to a PKI-trusted? Then great! I get a UI element (no prompt) showing the site is trusted. Does the site get a new self-signed cert? Back to the first step. I believe this, and the parent notion of default cert generation by apache installs, is better than no SSL. It's not as good as fully verifiable auth. --- And son of a gun, I know this isn't an original idea, but I can't believe it took another post to remind me this is exactly how SSH works. Sure, you can get the server key to your DO host and transfer it to your client, but how many people do that? They accept the fingerprint they see at first, assume it's good, and probably raise an eyebrow if it changes. Don't like it? OK, let's go back to telnet.
- MichaelGG 12y ago
  If state level actors wanted to MITM all SSH connections to make you accept the wrong key, they could. But it has a high chance of being caught as generally, you'll pay attention when the key changes. Plus you can reasonably verify the key out of band. (And one could imagine an extension to add a bit of CA-style key verification, like, "was this key generated by my account or my VPS provider, allowing you to manually verify one key and then being set for the rest.) Whereas if you do this on HTTP, a: you're constantly having a lot more "first time" connections. B: you've got no real way to know when the key changed legitimately. Users would quickly grow accustomed to key change warnings and ignore them. Or you'd see banners on sites like "ignore the key warning; I reinstalled my blog and the key changed". Attacks could even inject such a banner. If you want to manually verify every cert, you can already do that today: just go and add certs to your browser! Unauthed HTTPS-by-default just adds complexity and a false sense of security and isn't worth pushing out on the public.
  - deleted 12y ago
    [deleted]
MichaelGG 12y ago
Sure, but at least it means simple optical splitters can no longer read the contents of your web traffic. That's arguably not worth a whole lot, and may trick people into feeling safer when they shouldn't. But if nothing else changed (no browser indications, etc), wouldn't using DH on all HTTP be strictly better than nothing? Theoretically. In practice, I suppose entities just replace their splitters with a retransmitter and we're back to zero.
fryguy 12y ago
Encryption without authentication solves a majority of threat vectors that would allow people to look at your private communication. (authentication here means knowing that key K belongs to some organization, not authenticated encryption). If, by default, everything was encrypted, then the internet would be a much better place. Once encryption is in place, it means that active monitoring will be easy to detect because if only a small number of people actually verify that the remote party is who they say they are, then it will still be detected.
- tptacek 12y ago
  No, it doesn't. It stops a majority of primitive exploits. Breaking exploits is not the same thing as closing vulnerabilities.
101914 12y ago
Is this meant to be a general statement or just a response to some comment? One thing I do not like about the popular "strong" encryption solutions are that they are tied to relatively "weak" authentication solutions. Instead of two programs that each do one thing, we are instructed to use one program that does two things. I prefer that encryption and authentication were are viewed as distinct programs. If desired they can be used together. Sometimes we may not wish to rely on the hope of an "encrypted channel", but instead we might just want to send an encrypted blob over an untrusted channel (=the internet). Obviously it makes sense to send your encrypted blob to the correct destination, but that does not mean you _must_ use encryption to verify the destination is the correct one; it is an option, but not the only one. For example, it is possible to do the authentication part via some old-fashioned method that does not require the internet.
hobarrera 12y ago
Of course it is. It prevents passive eavesdropping, but is useless against active attackers. In the end, it's of little use, but that doesn't mean you can separate both things.

fleitz 12y ago

Yup, let's not let perfect become the enemy of good. SSH works basically this way, certs are autogenerated, the client records the key, and lets you know if it changes. And doesn't everyone recommend SSH over Telnet, despite certs mostly (never?) not being signed?