6 ms·

Is there a TL;DR version of how adding SSL will make it a whole lot better? Sorry to be dumb on this subject but my understanding of how email works (in particu

by rubyfan 11y ago

Is there a TL;DR version of how adding SSL will make it a whole lot better? Sorry to be dumb on this subject but my understanding of how email works (in particular SMTP) seems like the whole model is busted to begin with. Are we still sending basically plain text unsigned messages using something akin to the pony express? Does it matter that the pony express carriers communicates securely so no bad guys can snoop the carriers bag of messages At least in the old days you could put a wax seal on the letter to know the letter was legit and not tampered with. With email the entire system is flawed from the get go.

nxzero 11y ago
Agree, idea that the carrier should be trusted or for that matter responsible for the security of a message is dated and largely meaningless security measure. As long as the message is able to be read by anyone other than the sender and intended recipient the message should be assumed as being insecure.
baudehlo 11y ago
Here is my vague attempt at ELI5: Email is sent via a protocol called SMTP. SMTP goes over port 25 between major senders (there are other ports but forget that for now). Since it uses a single port, you can't distinguish between encrypted and plain text communication until you know each end supports encryption. A dated philosophy but people don't upgrade their email servers as often as they do their web browsers so it made sense at the time. Since the plain text receiving server says "yes I can do STARTTLS", this is easy to man in the middle intercept and say "no encryption here" and the mail goes through anyway. Even if the receiving end says all mail must arrive over TLS the man in the middle can currently circumvent that by receiving in plain text and forwarding onwards via TLS This is an RFC to try and prevent that happening. This stuff is hard, and email nerds (via MAAWG and various other places) have been working on this for years. We don't want to break your current email service, and bringing things up to speed without breaking a ton of eggs has been hurting email for a long time, but we spent too long stopping spam instead of thinking about these problems. Sorry!
- danmarg 11y ago
  I don't think the use of a single port is really at the heart of the problem. Even if SMTP with TLS ran over port 26 (say), you wouldn't know if a timeout on port 26 meant the server wasn't listening on port 26 or a MITM had just chosen to drop your packets. Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.
newman314 11y ago
You are right in that it's kind of lipstick on a pig. TLS encrypts inflight email, not at rest nor does it adequately protect associated metadata. BUT, it's better than not doing anything.
hellbanner 11y ago
Darkmail discussion: https://www.youtube.com/watch?v=TWzvXaxR6us https://www.youtube.com/watch?v=TWzvXaxR6us

by rubyfan 11y ago

nxzero 11y ago

Agree, idea that the carrier should be trusted or for that matter responsible for the security of a message is dated and largely meaningless security measure. As long as the message is able to be read by anyone other than the sender and intended recipient the message should be assumed as being insecure.

baudehlo 11y ago

Here is my vague attempt at ELI5: Email is sent via a protocol called SMTP. SMTP goes over port 25 between major senders (there are other ports but forget that for now). Since it uses a single port, you can't distinguish between encrypted and plain text communication until you know each end supports encryption. A dated philosophy but people don't upgrade their email servers as often as they do their web browsers so it made sense at the time. Since the plain text receiving server says "yes I can do STARTTLS", this is easy to man in the middle intercept and say "no encryption here" and the mail goes through anyway. Even if the receiving end says all mail must arrive over TLS the man in the middle can currently circumvent that by receiving in plain text and forwarding onwards via TLS This is an RFC to try and prevent that happening. This stuff is hard, and email nerds (via MAAWG and various other places) have been working on this for years. We don't want to break your current email service, and bringing things up to speed without breaking a ton of eggs has been hurting email for a long time, but we spent too long stopping spam instead of thinking about these problems. Sorry!

danmarg 11y ago
I don't think the use of a single port is really at the heart of the problem. Even if SMTP with TLS ran over port 26 (say), you wouldn't know if a timeout on port 26 meant the server wasn't listening on port 26 or a MITM had just chosen to drop your packets. Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.

newman314 11y ago

You are right in that it's kind of lipstick on a pig. TLS encrypts inflight email, not at rest nor does it adequately protect associated metadata. BUT, it's better than not doing anything.

hellbanner 11y ago

Darkmail discussion: https://www.youtube.com/watch?v=TWzvXaxR6us https://www.youtube.com/watch?v=TWzvXaxR6us