4 ms·

Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don

Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do? Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway. The moment you force TLS as a requirement, the internet starts having lots of large black holes in it due to the number of SMTP servers that don't support it (still) or don't have valid certificates. At that point email fails. However, the moment you agree to it, you are at the mercy of the root PKI (certificate authorities) who aren't necessarily all that trustworthy. Any fucker can buy an SSL certificate and masquerade as someone else. Also don't forget that CRL (revocation lists) exist that list naff CA certs that have been compromised. At that point, encryption fails. That's why it's fucked - whack-a-mole all over the place.

mike-cardwell 13y ago
"Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?" If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender. I know of at least the Exim and Postfix projects which are both working on adding DANE support to their MTAs. Also, even without any certificate verification, opportunistic SSL is extremely useful. It may not be able to stop targetted surveilance, but it can sure stop a large chunk (most?) of the dragnet style surveilance that has recently been reported. We should do the best we can with our current system until a new system is deployed. We don't know how long we'll be waiting.
- harrytuttle 13y ago
  DNSSEC+DANE is fine and all that, but that's another layer of hack job on top of another lacker of hackjob. It's turtles (or turds in this case) all the way down. The fact that a simple delivery stack turns into a mish-mash of SpamAssassin, virus scanning, DKIM, DNSSEC, DANE, SPF, PGP, certificates, CA's, numerous ports open, severla products and many more TLA's is the problem. Complexity does not breed security.
  - sorbits 13y ago
    Why is it a hack job? I would say it’s patching a hole, and it’s the feasible way to make email secure, rather than throw it all out and convince the world to switch to a new system. Most (internet) standards evolve this way. That’s the curse of evolving a standard that is already in widespread use.
    - harrytuttle 13y ago
      The hack job comes from the fact that it's not universal, nor does it provide a holistic solution. It is literally a sticky plaster. The problem is that sometimes standards are no longer fit for purpose on multiple levels. At this point, migration is required to new standards. This does happen quite regularly. Look at IPv4 to IPv6. The change should be of the same magnitude. We've done this before. First UUCP, then SMTP, then XYZ.
    - balabaster 13y ago
      Mostly because it rests on CA's and if the government can compel the CA to give them a signed cert for something that your security relies on, all they have to do is pose a MITM attack and you're blissfully clueless that they're spying on you. The whole system is broken and if you don't fix the foundations upon which your house is built, no amount of band-aids are going to keep the walls standing.
      - kyrias 13y ago
        No, with DANE nothing rests on CA's. With DANE domain owners store their keys in the DNS, and the DNS records are signed with DNSSEC
toomuchtodo 13y ago
I think that's the problem though. My browser connects to Gmail with SSL/TLS/HTTPS. The internet community moves fast when we decide something (Goodbye support for Internet Explorer 6!), why can't we decide on this: You will use a mail client that requires SSL to connect to our mail server, or one that does support SSL will be provided for you. Would you ever allow fallback to HTTP of authentication or credit card data? NO! It is time for unencrypted mail transport to die.
- seiji 13y ago
  Fast? IE6 was released in 2001 and people didn't start "dropping support" until 2008 or 2009. Unencrypted email is like unencrypted telephone calls. Imagine how to get the world to switch to using encrypted handsets.
  - nine_k 13y ago
    GSM communication is actually encrypted [1], albeit lightly. I remember having an unencrypted NMT handset and ditching it circa 2000 in favor of a GSM handset. NMT support was dropped by my service provider 3-4 years later. So transitions like this are definitely possible, though not overnight. Remember the slow introduction of https. [1] http://en.wikipedia.org/wiki/GSM#GSM_service_security http://en.wikipedia.org/wiki/GSM#GSM_service_security
    - tlrobinson 13y ago
      I think the parent comment was referring to end-to-end encrypted handsets. Phone calls are like email in that only some hops are encrypted.
    - bdcravens 13y ago
      You're forgetting POTS lines. I can call someone on a POTS line, with a 1992 handset, and it works the same as if I called someone with a brand new GSM phone.
      - nine_k 13y ago
qwerty_asdf 13y ago
> Any fucker can buy an SSL certificate and > masquerade as someone else. You lost me there. I'm not entirely convinced on that. How might I simply buy an SSL certificate and masquerade as https://www.google.com https://www.google.com?
- lucian1900 13y ago
  By convincing one of the trusted CAs to do so. Or if you're a government, forcing them.

mike-cardwell 13y ago

"Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?" If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender. I know of at least the Exim and Postfix projects which are both working on adding DANE support to their MTAs. Also, even without any certificate verification, opportunistic SSL is extremely useful. It may not be able to stop targetted surveilance, but it can sure stop a large chunk (most?) of the dragnet style surveilance that has recently been reported. We should do the best we can with our current system until a new system is deployed. We don't know how long we'll be waiting.

harrytuttle 13y ago
DNSSEC+DANE is fine and all that, but that's another layer of hack job on top of another lacker of hackjob. It's turtles (or turds in this case) all the way down. The fact that a simple delivery stack turns into a mish-mash of SpamAssassin, virus scanning, DKIM, DNSSEC, DANE, SPF, PGP, certificates, CA's, numerous ports open, severla products and many more TLA's is the problem. Complexity does not breed security.
- sorbits 13y ago
  Why is it a hack job? I would say it’s patching a hole, and it’s the feasible way to make email secure, rather than throw it all out and convince the world to switch to a new system. Most (internet) standards evolve this way. That’s the curse of evolving a standard that is already in widespread use.
  - harrytuttle 13y ago
    The hack job comes from the fact that it's not universal, nor does it provide a holistic solution. It is literally a sticky plaster. The problem is that sometimes standards are no longer fit for purpose on multiple levels. At this point, migration is required to new standards. This does happen quite regularly. Look at IPv4 to IPv6. The change should be of the same magnitude. We've done this before. First UUCP, then SMTP, then XYZ.
  - balabaster 13y ago
    Mostly because it rests on CA's and if the government can compel the CA to give them a signed cert for something that your security relies on, all they have to do is pose a MITM attack and you're blissfully clueless that they're spying on you. The whole system is broken and if you don't fix the foundations upon which your house is built, no amount of band-aids are going to keep the walls standing.
    - kyrias 13y ago
      No, with DANE nothing rests on CA's. With DANE domain owners store their keys in the DNS, and the DNS records are signed with DNSSEC

toomuchtodo 13y ago

I think that's the problem though. My browser connects to Gmail with SSL/TLS/HTTPS. The internet community moves fast when we decide something (Goodbye support for Internet Explorer 6!), why can't we decide on this: You will use a mail client that requires SSL to connect to our mail server, or one that does support SSL will be provided for you. Would you ever allow fallback to HTTP of authentication or credit card data? NO! It is time for unencrypted mail transport to die.

seiji 13y ago
Fast? IE6 was released in 2001 and people didn't start "dropping support" until 2008 or 2009. Unencrypted email is like unencrypted telephone calls. Imagine how to get the world to switch to using encrypted handsets.
- nine_k 13y ago
  GSM communication is actually encrypted [1], albeit lightly. I remember having an unencrypted NMT handset and ditching it circa 2000 in favor of a GSM handset. NMT support was dropped by my service provider 3-4 years later. So transitions like this are definitely possible, though not overnight. Remember the slow introduction of https. [1] http://en.wikipedia.org/wiki/GSM#GSM_service_security http://en.wikipedia.org/wiki/GSM#GSM_service_security
  - tlrobinson 13y ago
    I think the parent comment was referring to end-to-end encrypted handsets. Phone calls are like email in that only some hops are encrypted.
  - bdcravens 13y ago
    You're forgetting POTS lines. I can call someone on a POTS line, with a 1992 handset, and it works the same as if I called someone with a brand new GSM phone.
    - nine_k 13y ago

qwerty_asdf 13y ago

> Any fucker can buy an SSL certificate and > masquerade as someone else. You lost me there. I'm not entirely convinced on that. How might I simply buy an SSL certificate and masquerade as https://www.google.com https://www.google.com?

lucian1900 13y ago
By convincing one of the trusted CAs to do so. Or if you're a government, forcing them.