6 ms·

Encryption on the web is easy, because its automated by TLS. A far more concise answer is that email does not have an equivalent to TLS because it's architectu

Encryption on the web is easy, because its automated by TLS. A far more concise answer is that email does not have an equivalent to TLS because it's architecture is not the simple client-server model like the web. TLS is two layers of encryption. An outer layer using some form of PKI to form an encrypted pipe for the transfer of a symmetric key transfer then a more secure inner pipe based upon the symmetric key. https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Transport_Layer_Security That is vaguely straight forward to automate provided lots of agreement around various supported standards, because the client only has to communicate with a server that will automatically respond. Email architecture is more like client-server-server-client (and that understates many edge cases), or rather peer-to-peer with a variety of decentralized servers in the middle and the clients aren't stateful applications like how web browsers are dedicated to browsing the web. An email client on one end has no idea what the various servers and remote clients will support and when they will ever respond for a variety of technical reasons. Since email does not have TLS key exchange is manual unless both clients are on the same server and the server owns the process for establishing key exchange, session encryption to each party, and routing between each encrypted session.

dredmorbius 7y ago
TLS doesn't require long-term access. All encryption is session encryption -- data-in-flight. There's no data- or access-loss with key expiry (though there's a potential for data intercept with even session-key compromise). Keysystems such as SSH are similar in this regard. Encrypted email, and all data-at-rest encryption require long-term key retention and confidentiality. Loss of a key means loss of data. Disclosure of a key means loss of confidentiality. TLS / data-in-flight is a tremendously simpler problem than email / data-at-rest.
- austincheney 7y ago
  Websites require long term certificate retention and every year or two those certificates are replaced just like email PKI keys are in an environment with key management. So, long term crypto storage in that regard is equivalent between email and the web. The fact that the PKI keys of TLS are temporary are more out of convenience than security because the client/server have to work out which key set algorithm is agreeable. You don't generally need a certificate in addition to perform key exchange over email, though that is an option, because you either know and trust who you are manually exchanging keys with or the remote user is already trusted because you are both on the same server that is automating the exchange. On the web everything is anonymous so there is no trust without that certificate. If you really want one though modern email clients will allow you to create a personal certificate and digital signature to establish identity. Key exchange isn't meant to provide identity. That is what signed certificates are for. The keys are only there to provide distributed encryption. Most modern email clients will allow you to generate a certificate for your emails with a digital signature. https://en.wikipedia.org/wiki/Digital_signature https://en.wikipedia.org/wiki/Digital_signature
  - dredmorbius 7y ago
    Sorry, what's your source? Your link fails to address your assertion at all. Any website key retention is out of convention rather to ensure data access, and a convention Let's Encrypt is fast upending: The certificate is valid for 90 days, during which renewal can take place at any time. https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt Key exchange is a component of PKI. You either need to know, or be able to request, a given key to validate it, or transmissions based on it. TLS (as SSL before it) relies on certificate authorities (CAs), whose keys 1) are distributed to all major browsers and/or operating systems, and 2) which then vouch for website keys. Other mechanisms (e.g., key pinning) are also used. This model has many critics. PGP (or Gnupg, and alternate implementation) rely, also to various degrees of general criticism, on a web of trust model, in which keys are signed by various other keys, possibly but not necessarily the user's own. Trust is ideally personally verified. It's been observed that this poses scaling issues. Other PKI models have their own approaches to key trust. S/MIME uses CAs similarly to TLS/SSL, for key authentication, but keys themselves must still be retained, and secured, to assure future data access and integrity. SSH effectively relies on TOFU (trust on first use) or OOB (out of band) key distribution -- both of which effectively punt the process. TLS, SSL, and SSH are all session-based (data-in-flight) protocols. PGP and S/MIME are storage-oriented, data-at-rest protocols. My initial comments apply to each.
    - austincheney 7y ago
      > Sorry, what's your source? https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithm https://en.wikipedia.org/wiki/Transport_Layer_Security#Algor... Yes, the Let's Encrypt certificates are valid for only 90 days. > whose keys 1) are distributed to all major browsers and/or operating systems Not exactly. Root certificates are widely distributed to user-agent applications but the actual website certificates are available upon request from visiting the sites. A CA is an issuing authority for certificates. Certificates are not directly a component of encryption, but serve to validate the encryption is trusted. * https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate * https://en.wikipedia.org/wiki/Certificate_authority https://en.wikipedia.org/wiki/Certificate_authority * https://en.wikipedia.org/wiki/Public_key_certificate https://en.wikipedia.org/wiki/Public_key_certificate * certificate distribution schemes - https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_compsci134/slides/LEC12-KED.pdf https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_comp...
deleted 7y ago
[deleted]
Shendare 7y ago
I am a layperson, so the answer is probably painfully obvious, but why can't e-mail have TLS-style key exchange, where the sender's server gets the public key from the recipient's server and encrypts the message with it before sending it over? The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key. Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails. But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.
- austincheney 7y ago
  The keys don’t come from the servers but from the end users, so the remote server won’t have the remote user’s key. > Or they could let their provider hold onto a copy of the private key Then the key is no longer private. The idea of a private key is not to share or distribute it.
  - Shendare 7y ago
    Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request? Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all. Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.
    - austincheney 7y ago
      > Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request? They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated. The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with. Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.
zokier 7y ago
> email does not have an equivalent to TLS Email does have the equivalent of TLS, its TLS. Send a message to another user in Facebook or whatev over the web and its secured by TLS over the wire, but does not protect from the server reading it. Send a email to user on an email server and its secured by TLS over the wire, but does not protect the server from reading it. Exactly the same thing.
- austincheney 7y ago
  > over the web So this confuses a few things. Technically you are right in that TLS applies to the transport layer (layer 4) while both web and email are application layer (layer 7), but then the question is how to apply it for email in practice that differs from manual key exchange? Web mail uses web (port 80 or 443) to communicate to a web server email application where the email is blasted out as regular email (most likely as SMTP over port 25). Since the first leg is regular web traffic regular web rules apply, but only to that first leg. Applications like Outlook and Thunderbird are not webmail and do not use web traffic to send/receive email.
tialaramex 7y ago
Your layered model with "pipes" seems like a confusion and is misleading at best. It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more. In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said. Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode). Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to. There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.
- austincheney 7y ago
  This website explains the distinct “pipes” better and more precisely than does the Wikipedia article: https://hpbn.co/transport-layer-security-tls/ https://hpbn.co/transport-layer-security-tls/ Those pipes are the asymmetric handshake to exchange the shared secret and the symmetric encryption provided by that shared secret. Certificates do not provide encryption and thus are not a “pipe”. Certificates are used to prove the identity of one of the end points (the server).
  - tialaramex 7y ago

dredmorbius 7y ago

TLS doesn't require long-term access. All encryption is session encryption -- data-in-flight. There's no data- or access-loss with key expiry (though there's a potential for data intercept with even session-key compromise). Keysystems such as SSH are similar in this regard. Encrypted email, and all data-at-rest encryption require long-term key retention and confidentiality. Loss of a key means loss of data. Disclosure of a key means loss of confidentiality. TLS / data-in-flight is a tremendously simpler problem than email / data-at-rest.

austincheney 7y ago
Websites require long term certificate retention and every year or two those certificates are replaced just like email PKI keys are in an environment with key management. So, long term crypto storage in that regard is equivalent between email and the web. The fact that the PKI keys of TLS are temporary are more out of convenience than security because the client/server have to work out which key set algorithm is agreeable. You don't generally need a certificate in addition to perform key exchange over email, though that is an option, because you either know and trust who you are manually exchanging keys with or the remote user is already trusted because you are both on the same server that is automating the exchange. On the web everything is anonymous so there is no trust without that certificate. If you really want one though modern email clients will allow you to create a personal certificate and digital signature to establish identity. Key exchange isn't meant to provide identity. That is what signed certificates are for. The keys are only there to provide distributed encryption. Most modern email clients will allow you to generate a certificate for your emails with a digital signature. https://en.wikipedia.org/wiki/Digital_signature https://en.wikipedia.org/wiki/Digital_signature
- dredmorbius 7y ago
  Sorry, what's your source? Your link fails to address your assertion at all. Any website key retention is out of convention rather to ensure data access, and a convention Let's Encrypt is fast upending: The certificate is valid for 90 days, during which renewal can take place at any time. https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt Key exchange is a component of PKI. You either need to know, or be able to request, a given key to validate it, or transmissions based on it. TLS (as SSL before it) relies on certificate authorities (CAs), whose keys 1) are distributed to all major browsers and/or operating systems, and 2) which then vouch for website keys. Other mechanisms (e.g., key pinning) are also used. This model has many critics. PGP (or Gnupg, and alternate implementation) rely, also to various degrees of general criticism, on a web of trust model, in which keys are signed by various other keys, possibly but not necessarily the user's own. Trust is ideally personally verified. It's been observed that this poses scaling issues. Other PKI models have their own approaches to key trust. S/MIME uses CAs similarly to TLS/SSL, for key authentication, but keys themselves must still be retained, and secured, to assure future data access and integrity. SSH effectively relies on TOFU (trust on first use) or OOB (out of band) key distribution -- both of which effectively punt the process. TLS, SSL, and SSH are all session-based (data-in-flight) protocols. PGP and S/MIME are storage-oriented, data-at-rest protocols. My initial comments apply to each.
  - austincheney 7y ago
    > Sorry, what's your source? https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithm https://en.wikipedia.org/wiki/Transport_Layer_Security#Algor... Yes, the Let's Encrypt certificates are valid for only 90 days. > whose keys 1) are distributed to all major browsers and/or operating systems Not exactly. Root certificates are widely distributed to user-agent applications but the actual website certificates are available upon request from visiting the sites. A CA is an issuing authority for certificates. Certificates are not directly a component of encryption, but serve to validate the encryption is trusted. * https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate * https://en.wikipedia.org/wiki/Certificate_authority https://en.wikipedia.org/wiki/Certificate_authority * https://en.wikipedia.org/wiki/Public_key_certificate https://en.wikipedia.org/wiki/Public_key_certificate * certificate distribution schemes - https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_compsci134/slides/LEC12-KED.pdf https://www.ics.uci.edu/~keldefra/teaching/fall2016/uci_comp...

deleted 7y ago

[deleted]

Shendare 7y ago

I am a layperson, so the answer is probably painfully obvious, but why can't e-mail have TLS-style key exchange, where the sender's server gets the public key from the recipient's server and encrypts the message with it before sending it over? The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key. Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails. But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.

austincheney 7y ago
The keys don’t come from the servers but from the end users, so the remote server won’t have the remote user’s key. > Or they could let their provider hold onto a copy of the private key Then the key is no longer private. The idea of a private key is not to share or distribute it.
- Shendare 7y ago
  Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request? Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all. Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.
  - austincheney 7y ago
    > Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request? They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated. The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with. Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.

zokier 7y ago

> email does not have an equivalent to TLS Email does have the equivalent of TLS, its TLS. Send a message to another user in Facebook or whatev over the web and its secured by TLS over the wire, but does not protect from the server reading it. Send a email to user on an email server and its secured by TLS over the wire, but does not protect the server from reading it. Exactly the same thing.

austincheney 7y ago
> over the web So this confuses a few things. Technically you are right in that TLS applies to the transport layer (layer 4) while both web and email are application layer (layer 7), but then the question is how to apply it for email in practice that differs from manual key exchange? Web mail uses web (port 80 or 443) to communicate to a web server email application where the email is blasted out as regular email (most likely as SMTP over port 25). Since the first leg is regular web traffic regular web rules apply, but only to that first leg. Applications like Outlook and Thunderbird are not webmail and do not use web traffic to send/receive email.

tialaramex 7y ago

Your layered model with "pipes" seems like a confusion and is misleading at best. It's probably easiest to see what's actually going on the TLS 1.3 design - even though this is effectively what really happens in popular clients and servers with older TLS versions today also - because in TLS 1.3 none of it's optional any more. In TLS 1.3 the peers agree an ephemeral shared "master" secret using an elliptic curve variant of the Diffie Hellman algorithm and random data they've chosen. ECDHE means each side ends up knowing the same essentially random secret and nobody else knows what that is, even if they eavesdropped on everything both peers said. Then this shared secret is enough to generate a number of symmetric keys used to secure all subsequent communications between the peers with conventional symmetric encryption (often AES using the GCM cipher mode). Now, the two peers can communicate securely, it is impossible for anyone to eavesdrop. But, at this stage neither is sure who the other is. It is conventional (in web browsers) for the client's identity to remain unknown in TLS but the server proves its identity using a signature algorithm. Specifically it signs a transcript of the process so far, proving that it took part in the sequence of events that led to this point, using a key for which it presents a certificate. The client can examine the certificate and signature and verify that the certificate is trustworthy and that the transcript signature proves that the certificate's subject is the server it is talking to. There aren't two pipes, one contained within the other. There's just one pipe, a secure pipe between client and server, and then that pipe is used to transport proof of the server's identity (and optionally, likewise for the client). Without that identity the pipe is still secure, you just don't know who it is you're talking to securely.

austincheney 7y ago
This website explains the distinct “pipes” better and more precisely than does the Wikipedia article: https://hpbn.co/transport-layer-security-tls/ https://hpbn.co/transport-layer-security-tls/ Those pipes are the asymmetric handshake to exchange the shared secret and the symmetric encryption provided by that shared secret. Certificates do not provide encryption and thus are not a “pipe”. Certificates are used to prove the identity of one of the end points (the server).
- tialaramex 7y ago