6 ms·

This is very interesting. I think a better approach might be to separate encryption from trust. I'm thinking back to Chrome's announcement that they were cons

by Navarr 12y ago

This is very interesting. I think a better approach might be to separate encryption from trust. I'm thinking back to Chrome's announcement that they were considering making http:// http:// show some sort of warning. What if: * We make HTTP show up as "insecure" in browsers * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http * We make HTTPS with Trust show up the way we currently show HTTPS * Keep EV Certs the same

diafygi 12y ago
Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
spectre256 12y ago
I might be wrong,, but it seems like trust and encryption are fundamentally linked. For example, in the case of self-signed certificates, the browser knows it is encrypting a message to the holder of the self-signed certificate, but there's no information on who that is. The certificate sent could be changed, and there's no way to know something is wrong. Put another way, plain text is readable by anyone. Text properly encrypted to a known recipient is readable only by that recipient. But text encrypted to an unknown recipient is readable by only one entity, but that entity could be anyone, so it's equivalent to plain text.
- pdkl95 12y ago
  Trust (authentication) and encryption are linked... iff your threat model includes defending against MitM attacks. For threat models that merely try to defend against trivial passive eavesdropping (such as bulk XKEYSCORE style surveillance or even just the local busybody that just learned how to use tcpdump), encryption alone is very useful. I strongly recommend using full authentication whenever possible, of course, but in the cases where that is not (yet?) practical, enabling auto-generated self-signed certificates for TLS should usually be a very simple change. Really, the only people that I expect would be against such an easy change are people doing NSA-style spying or businesses with a surveillance-based business model.
  - MichaelGG 12y ago
    The local busybody - how are they attacking you? On WiFi or arp poisoning scenarios, they can MitM with the same setup they're already using. If there was a big shift to encryption without verification, passive attacks could just start shifting to active ones. In most cases they're in place to do so. I suppose the major exception is optical splitter scenarios. But what's stopping them from replacing the splitter with another hop?
    - pdkl95 12y ago
      > If there was a big shift to encryption without verification Shift from WHAT? Remember, nobody is suggesting shifting anything from proper encryption, or changing the UI in any way that might mislead a user into thinking they were using a "secure" connection. This is a replacement for plaintext only. > But what's stopping them from replacing the splitter with another hop? Cost and complexity. Which is to say, if anybody really wants to throw a few megabucks at the problem, they will succeed, but that is not a contingency that some threat models worry about. I will refer to Dan Geer when he said[1] (and I suggest this is true for the corporation as well as government): The central dynamic internal to government is, and always has been, that the only way ... to control the many sub-units of government is by way of how much money [it] can hand out. ... Suppose, however, that surveillance becomes too cheap to meter, that is to say too cheap to limit through budgetary processes. This is what technology has done for the surveillance of plaintext. The marginal cost of recording "everybody"[2] went form about 1:1 in man-hours to practically free, largely because it is possible to log all the plaintext you want to disk, to be processed as needed (or to data mine). By raising the cost at all, we might be moving at least some types of eavesdropping back from "too cheap to limit". Make the eavesdropper work for it, instead of simply folding because they might decide to upgrade to a MitM. An even better question, though, is why are you so interested in keeping the internet in plaintext? [1] http://geer.tinho.net/geer.blackhat.6viii14.txt http://geer.tinho.net/geer.blackhat.6viii14.txt [2] for whatever definition of "everybody" you prefer
      - MichaelGG 12y ago
        Some proposals were to warn about HTTP without OE, and then display the current HTTP plaintext UI for HTTP with OE. So long as there's no distinction to the end user UI so plaintext looks as good as OE, then I'm all for it.
agwa 12y ago
> * We make HTTP show up as "insecure" in browsers > * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Clear text and opportunistic encryption should have exactly the same UI. Security UIs are already too confusing, and we shouldn't introduce more complexity. Besides, one should never make a decision based on a clear text vs OE distinction, since OE is so easily defeated.
- belorn 12y ago
  I guess this is why most administrators use telnet instead of ssh, since they don't have time to check ssh fingerprints... Well, not really. As it is, many people do make a decision based on a clear text vs OE. Now if just Firefox would store and check fingerprints of self-signed certificates, we would get the exact same benefit when telnet was replaced by ssh.
  - copsarebastards 12y ago
    Administrators are a much more sophisticated group than average users. Presenting telnet/SSH as equivalent to HTTP/HTTPS is silly because they have drastically different use cases.
    - wongarsu 12y ago
      I think his point is that ssh is just opportunistic encryption if you don't compare the fingerprint at the first connection. Anybody could just MitM your first connection to the server without you noticing, and then MitM every future connection as well. In a sense telnet/ssh is exactly like http/http_with_oe. And still we make a big deal out of the telnet/ssh difference while saying that http with OE is only marginally better than http. Of course it's not nearly that black and white because ssh stores the fingerprint, meaning you are safe if (and only if) your first connection wasn't intercepted.
  - IgorPartola 12y ago
    You don't check ssh fingerprints?
higherpurpose 12y ago
I think that's basically what the Chrome guys proposed.
- Navarr 12y ago
  I think so too, but I don't recall them opening the doors for self-signed HTTPs as on-par with HTTP
upofadown 12y ago
>We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Then how do you know you are getting any sort of encryption?
- Navarr 12y ago
  Because the HTTP shows up as insecure, for one.

by Navarr 12y ago

diafygi 12y ago

Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087

spectre256 12y ago

I might be wrong,, but it seems like trust and encryption are fundamentally linked. For example, in the case of self-signed certificates, the browser knows it is encrypting a message to the holder of the self-signed certificate, but there's no information on who that is. The certificate sent could be changed, and there's no way to know something is wrong. Put another way, plain text is readable by anyone. Text properly encrypted to a known recipient is readable only by that recipient. But text encrypted to an unknown recipient is readable by only one entity, but that entity could be anyone, so it's equivalent to plain text.

pdkl95 12y ago
Trust (authentication) and encryption are linked... iff your threat model includes defending against MitM attacks. For threat models that merely try to defend against trivial passive eavesdropping (such as bulk XKEYSCORE style surveillance or even just the local busybody that just learned how to use tcpdump), encryption alone is very useful. I strongly recommend using full authentication whenever possible, of course, but in the cases where that is not (yet?) practical, enabling auto-generated self-signed certificates for TLS should usually be a very simple change. Really, the only people that I expect would be against such an easy change are people doing NSA-style spying or businesses with a surveillance-based business model.
- MichaelGG 12y ago
  The local busybody - how are they attacking you? On WiFi or arp poisoning scenarios, they can MitM with the same setup they're already using. If there was a big shift to encryption without verification, passive attacks could just start shifting to active ones. In most cases they're in place to do so. I suppose the major exception is optical splitter scenarios. But what's stopping them from replacing the splitter with another hop?
  - pdkl95 12y ago
    > If there was a big shift to encryption without verification Shift from WHAT? Remember, nobody is suggesting shifting anything from proper encryption, or changing the UI in any way that might mislead a user into thinking they were using a "secure" connection. This is a replacement for plaintext only. > But what's stopping them from replacing the splitter with another hop? Cost and complexity. Which is to say, if anybody really wants to throw a few megabucks at the problem, they will succeed, but that is not a contingency that some threat models worry about. I will refer to Dan Geer when he said[1] (and I suggest this is true for the corporation as well as government): The central dynamic internal to government is, and always has been, that the only way ... to control the many sub-units of government is by way of how much money [it] can hand out. ... Suppose, however, that surveillance becomes too cheap to meter, that is to say too cheap to limit through budgetary processes. This is what technology has done for the surveillance of plaintext. The marginal cost of recording "everybody"[2] went form about 1:1 in man-hours to practically free, largely because it is possible to log all the plaintext you want to disk, to be processed as needed (or to data mine). By raising the cost at all, we might be moving at least some types of eavesdropping back from "too cheap to limit". Make the eavesdropper work for it, instead of simply folding because they might decide to upgrade to a MitM. An even better question, though, is why are you so interested in keeping the internet in plaintext? [1] http://geer.tinho.net/geer.blackhat.6viii14.txt http://geer.tinho.net/geer.blackhat.6viii14.txt [2] for whatever definition of "everybody" you prefer
    - MichaelGG 12y ago
      Some proposals were to warn about HTTP without OE, and then display the current HTTP plaintext UI for HTTP with OE. So long as there's no distinction to the end user UI so plaintext looks as good as OE, then I'm all for it.

agwa 12y ago

> * We make HTTP show up as "insecure" in browsers > * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Clear text and opportunistic encryption should have exactly the same UI. Security UIs are already too confusing, and we shouldn't introduce more complexity. Besides, one should never make a decision based on a clear text vs OE distinction, since OE is so easily defeated.

belorn 12y ago
I guess this is why most administrators use telnet instead of ssh, since they don't have time to check ssh fingerprints... Well, not really. As it is, many people do make a decision based on a clear text vs OE. Now if just Firefox would store and check fingerprints of self-signed certificates, we would get the exact same benefit when telnet was replaced by ssh.
- copsarebastards 12y ago
  Administrators are a much more sophisticated group than average users. Presenting telnet/SSH as equivalent to HTTP/HTTPS is silly because they have drastically different use cases.
  - wongarsu 12y ago
    I think his point is that ssh is just opportunistic encryption if you don't compare the fingerprint at the first connection. Anybody could just MitM your first connection to the server without you noticing, and then MitM every future connection as well. In a sense telnet/ssh is exactly like http/http_with_oe. And still we make a big deal out of the telnet/ssh difference while saying that http with OE is only marginally better than http. Of course it's not nearly that black and white because ssh stores the fingerprint, meaning you are safe if (and only if) your first connection wasn't intercepted.
- IgorPartola 12y ago
  You don't check ssh fingerprints?

higherpurpose 12y ago

I think that's basically what the Chrome guys proposed.

Navarr 12y ago
I think so too, but I don't recall them opening the doors for self-signed HTTPs as on-par with HTTP

upofadown 12y ago

>We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Then how do you know you are getting any sort of encryption?

Navarr 12y ago
Because the HTTP shows up as insecure, for one.