5 ms·

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

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.

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.