4 ms·

There is no reasonable way to encrypt emails. It’s far too easy to reply to the message without encryption or something of the sort. Email was never designed

There is no reasonable way to encrypt emails. It’s far too easy to reply to the message without encryption or something of the sort. Email was never designed to be encrypted.

dane-pgp 5y ago
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.
jandrese 5y ago
There are reasonable ways to encrypt email, we just don't have them. PGP is not it, and I think PGP is at least partially responsible for actual working solutions never materializing. The PGP developers are too paranoid to develop a system that actually works. The web of trust is ridiculous overkill for most users, and should have been an option for really paranoid people, not the default. But because of the web of trust there is no good official scalable way to transfer public keys and thus the whole system doesn't work. Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.

There is no reasonable way to encrypt emails. It’s far too easy to reply to the message without encryption or something of the sort. Email was never designed to be encrypted.

dane-pgp 5y ago

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.

jandrese 5y ago

There are reasonable ways to encrypt email, we just don't have them. PGP is not it, and I think PGP is at least partially responsible for actual working solutions never materializing. The PGP developers are too paranoid to develop a system that actually works. The web of trust is ridiculous overkill for most users, and should have been an option for really paranoid people, not the default. But because of the web of trust there is no good official scalable way to transfer public keys and thus the whole system doesn't work. Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.