Slashdot Mirror

← Back to Stories (view on slashdot.org)

EFF Announces STARTTLS Everywhere To Help Make Email Delivery More Secure (betanews.com)

Posted by msmash on from the step-in-the-right-direction dept.

Mark Wilson writes: When it comes to messaging tools, people have started to show greater interest in whether encryption is used for security, and the same for websites -- but not so much with email. Thanks to the work of the Electronic Frontier Foundation, however, email security is being placed at the top of the agenda. The privacy group today announces STARTTLS Everywhere, its new initiative to improve the security of the email ecosystem. STARTTLS is an addition to SMTP, and while it does not add end-to-end encryption, it does provide hop-to-hop encryption, which is very much a step in the right direction. In a blog post, EFF elaborates SMARTTLS for the uninitiated, and outlines how it worked around some of the tech's underlying challenges: There are two primary security models for email transmission: end-to-end, and hop-to-hop. Solutions like PGP and S/MIME were developed as end-to-end solutions for encrypted email, which ensure that only the intended recipient can decrypt and read a particular message. Unlike PGP and S/MIME, STARTTLS provides hop-to-hop encryption (TLS for email), not end-to-end. Without requiring configuration on the end-user's part, a mailserver with STARTTLS support can protect email from passive network eavesdroppers. For instance, network observers gobbling up worldwide information from Internet backbone access points (like the NSA or other governments) won't be able to see the contents of messages, and will need more targeted, low-volume methods. In addition, if you are using PGP or S/MIME to encrypt your emails, STARTTLS prevents metadata leakage (like the "Subject" line, which is often not encrypted by either standard) and can negotiate forward secrecy for your emails.

9 of 58 comments (clear)

  1. This doesn't help man-in-the-middle attacks by greenwow · · Score: 2

    Since you can just make it appear that TLS is unavailable.

    1. Re:This doesn't help man-in-the-middle attacks by crow · · Score: 4, Informative

      This raises the effort required from passive snooping to active interception. This is a good thing. This is an attempt to break mass surveillance.

    2. Re:This doesn't help man-in-the-middle attacks by KiloByte · · Score: 5, Informative

      Solved with DNSSEC+DANE, which for SMTP actually sees some deployment, unlike HTTPS, where anyone who can control one of 400+ CAs, which includes every government and big enough organized crime organization, can produce validly signed certs. With DNSSEC, you'd need to take over either the registrar or TLD -- unlike the CA model, the specific registrar your target uses rather than any of them.

      If you try to man-in-the-middle DNSSEC, all you get is a failure to deliver the mail. Which any properly configured server (ie, not Gmail) will report to the sender.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    3. Re:This doesn't help man-in-the-middle attacks by F.Ultra · · Score: 2

      Because e.g with STARTTLS you can make a quick connect to the SMTP port, upgrade to TLS if the other end-point supports it (and optionally disconnect if it doesn't) while with explicit TLS you have to first make a connection attempt to port 465 which can be a latency killer if there is no one listening and the RST is filtered by corporate FW.

      Also explicit TLS can be disabled at corporation due to clueless IT that doesn't want to open another port so here a simple upgrade of $SMTPD introduces TLS support where it otherwise would be disabled.

      Yes this opens for MiTM but if the default (and I assume that it is) for TLS enabled servers to try TLS first and then fallback to plaintext SMTP then they are also susceptible to the very same MiTM. A STARTTLS implementation does not have to susceptible to MiTM since it can drop the connection if the other end-point does not say that it supports TLS in the server EHLO.

  2. This is weak. by fisted · · Score: 4, Insightful

    STARTTLS means upgrading an existing plaintext connection to TLS. Mail servers announce (upon EHLO) what features they support, "starttls" can be one of those. When no "starttls" is advertised, the client will not upgrade and keep using the plaintext connection.

    Now, connection security only matters if someone has the ability to listen in to the connection. If someone can listen in, they likely can modify the traffic as well. So here's how to break STARTTLS: Remove the 'starttls' capability from the MTA's EHLO response. Done.

    The correct solution would be to unconditionally run SMTP-over-TLS (SMTPS) on a dedicated-for-that port (as is already common practice) and remove the plaintext listener if feasible.

    To repurpose a quote about OCSP: "STARTTLS is like a seat belt that always works, except when you're having an accident."

    --
    CLI paste? paste.pr0.tips!
    1. Re:This is weak. by Anonymous Coward · · Score: 3, Interesting

      The solution needs more than that because most mail servers are using self-signed certificates. There is no chain of authority or anything. That means you basically have to trust any certificate. So a man in the middle could easily use their own certificate and your server wouldn't even notice.

    2. Re:This is weak. by GreyFish · · Score: 2

      The presence of a DNSSEC signed DANE/TLSA record for the mail server indicates to other MTA's that the server only does STARTTLS - if STARTTLS is missing from the SMTP dialogue then the other MTA's will refuse to send. Support is available in postfix and exim etc...

    3. Re:This is weak. by bill_mcgonigle · · Score: 2

      When no "starttls" is advertised, the client will not upgrade and keep using the plaintext connection.

      That's completely up to the client. Where it matters I have mine configured to stop if STARTTLS isn't successful.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  3. Kill it with fire by shellster_dude · · Score: 2

    In 2018 we should be putting a bullet through the head of unencrypted SMTP and insecure protocols like STARTTLS. I've been running my mail server only allowing secure SMTP over TLS with medium grade ciphers or better, and IMAPS (and only allowing email sending if over secure connection). I've yet to run into issues in the last two years. The only problem is that some people's mail servers keep groping my box for port 25 first, instead of just trying SMTP/TLS and then failing if it can't. For the few devices I have that can't handle SMTP over TLS, I either replace them, or when I can't, I run them over a VPN, and whitelist their IP.