3 ms·

There is no reasonable way to encrypt web traffic. It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like

There is no reasonable way to encrypt web traffic. It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like an email). The web was never designed to be encrypted.

iggldiggl 5y ago
Web traffic reduced to its simplest case happens synchronously between two parties: Me, the client, and the server providing the resource I want to access. Encrypting the communication between those two points breaks various people in-between who want to listen in with varying degrees of legitimacy (others can't listen in on my traffic, but on the other hand I can't e.g. listen in on the traffic of IoT-devices in my home network any more, either), but it doesn't break anything a regular end user might immediately care about. Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.) If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents: - Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail
marwis 5y ago
Microsoft actually has ways of preventing that with information labeling. I used to work on company laptop that was using this extensively and it was not possible to copy something from higher to lower confidentiality. At least easily, there was a loophole involving cmd.exe.
sgjohnson 5y ago
You are absolutely correct. With web traffic encryption, you’re putting ALL your trust in ALL of the root certificates on your system. And this has about the same number of possible failure points than PGP encrypted emails. Trick a user into installing a root cert? Game over. Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee) Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is. HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.

iggldiggl 5y ago

Web traffic reduced to its simplest case happens synchronously between two parties: Me, the client, and the server providing the resource I want to access. Encrypting the communication between those two points breaks various people in-between who want to listen in with varying degrees of legitimacy (others can't listen in on my traffic, but on the other hand I can't e.g. listen in on the traffic of IoT-devices in my home network any more, either), but it doesn't break anything a regular end user might immediately care about. Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.) If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents: - Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail

marwis 5y ago

Microsoft actually has ways of preventing that with information labeling. I used to work on company laptop that was using this extensively and it was not possible to copy something from higher to lower confidentiality. At least easily, there was a loophole involving cmd.exe.

sgjohnson 5y ago

You are absolutely correct. With web traffic encryption, you’re putting ALL your trust in ALL of the root certificates on your system. And this has about the same number of possible failure points than PGP encrypted emails. Trick a user into installing a root cert? Game over. Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee) Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is. HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.