back to article In non-startling news, EFF says STARTTLS email crypto is mostly done wrong

Having successfully pushed for universal HTTPS Web encryption, the Electronic Frontier Foundation's next protocol push is for “STARTTLS Everywhere”. It's testament to system administrator inertia that a protocol first published in 2002 and available in all major e-mail clients and servers is still not everybody's default. By …

  1. ds6 Silver badge
    Black Helicopters

    Whether or not the data part of email is a suitable form of communication aside, can we not just nuke the whole implementation of mail transport? Every MTA/SMTP project is a cluttered mess (quite specifically sendmail, woof), and the specs they're based on are even more convoluted. If it's not coded so shoddily it could be pushed over with a brisk swat (again, sendmail), it's overcomplicated and difficult to work on/with—and probably not because the project maintainers want it to be.

    I don't see it being that difficult to create a specification based entirely around SSL/TLS with much simpler operating parameters that can still funnel mail through, since MIME is flexible.

    The difficult part would of course be getting people to adopt it. I bet some people even still use desktop Outlook, the barbarians.

    And now, to make a quick getaway before all the devout followers of sendmail come to raise me on a stake... If there are any left.

  2. john.jones.name

    opportunity

    what this should be about is DANE

    https://tools.ietf.org/html/rfc7671

    If people deploy this then things get a lot easier and trustworthy in TLS...

    The bonus is that its not tied to a Certificate Authority (CA) if you don't want it to be, which most mail servers is a good thing as they often have self certified certificates and if you have a Certificate from a CA then hey use it and declare it via DANE...

    https://www.ncsc.nl/english/current-topics/factsheets/factsheet-secure-the-connections-of-mail-servers.html

    you can test here : https://www.internet.nl/test-mail/

    strangely the dutch security service demand this as a secure channel I wonder what they know (-;

    1. Chronos

      Re: opportunity

      DANE is rather time-consuming if you're using Letsencrypt. LE certificates expire every three months, realistically two and a bit, so there's an overhead there of updating your TLSA record every time the certificate fingerprint changes.

      1. john.jones.name

        set it up right...

        DANE is not time consuming (any more than a certificate is) you just have to set it up correctly.

        you don't have to roll your certs if you don't want to and even if you do a script can automate it

  3. John Doe 6

    Actually...

    ...the problem is NOT the TLS part but the certificate part.

    I have to pay for something I am fully capable of providing - that sucks.

    1. Anonymous Coward
      Anonymous Coward

      Re: Actually...

      do not pay a cent simply declare your cert via DANE

      1. djack

        Re: Actually...

        .. or if you use letsencrypt as the CA, which the mention of certbot seems to be advocating even if it's not explicitly mentioned in the text.

        it's not difficult to do, even without an updated version of certbot.

        1. SJA

          acme.sh

          On my servers I use amce.sh as client for Let's Encrypt. It's a "simple" bash script with no real dependencies except openssl and curl/wget - so pretty much everywhere usable.... syntax is very simple and it also supports dns-01 (if you have a supported dns provider).

          The certs issued I use for apache, postfix, dovecot, syncthing and other services. They work really fine.

      2. Drew 11

        Re: Actually...

        DANE is dead in the water until the bowser manufacturers bake it into their browsers and Apple allow their OS to accept the certs from mail servers.

        Perhaps ICANN's SSAC could lean on them to adopt, but that's too obvious.

    2. Anonymous Coward Silver badge

      Re: Actually...

      I use certbot in certonly mode and have scripts to move certificates into appropriate places and reload corresponding services. Works fine for sendmail, dovecot, ftp, apache, lighttpd, ... especially now they can do wildcard certificates (*.your-domain)

  4. Brian Scott

    Email transport is insecure

    Get over it and move on.

    The only secure way to communicate via email is with end to end encryption using something like pgp.

    The fundamental problem with starttls is that if the certificate on the other end fails for some reason then it can 1) use it anyway, 2) downgrade to non-encrypted, or 3) bounce the email back to the sender. Number 3 is pretty unfriendly for the average user to work around. Number 2 is just stupid because the connection may be legitimate but with a self-signed certificate (or expired, wrong name, whatever) and the encryption would still defeat anyone listening to the connection. Alternative number 1 wins by default.

    DANE is good (provided you can use DNSSEC to authenticate it) but support is crap. Also, because of the multi-hop nature of email it is still only protecting an individual hop (although that is probably enough for uncomplicated email these days). Fake headers could be added by anyone along the way claiming encryption when it isn't used (why you would is beyond me if you can fiddle the headers then you already have access to the content).

    However, all this is solved if your email client encrypts the message in a way that it can't be decrypted until the destination email client decrypts it. The worst that an adversary can do is stop the email from being delivered. This is something that already happens regularly with over zealous spam checkers so is now an inherent problem with email anyway.

    1. Anonymous Coward
      Anonymous Coward

      Re: Email transport is insecure

      According to our isp Cisco released a fw update 2-3 years ago that changed a default so that they downgrades starttls requests, ie mitm pretending to each mailserver at each end that they don't support STARTTLS. How bad is that!. It is definitely an option in their routers to help them sell another service.

      I'm now going to put checks in for remote sites that downgrade connections. For where this occurs I bet there is a Cisco router in the middle.

    2. john.jones.name
      Holmes

      Email transport could be better

      You can enforce TLS and you can declare your certificate via DANE easily and simply.

      The CA model itself is not all that robust, and there are still some critical vulnerabilities that can be exploited by a well-resourced attacker. Adding DANE TSLA records to the DNS signed zone then with an additional DNS lookup to fetch and validate the TLSA record is a small step, but a significant improvement to the overall security picture.

  5. Christian Berger

    Yeah, but CAs are not really that trustworthy

    And checking CAs won't bring you much more security. In fact one could argue that since you already looked up the DNS record you already have a central system telling you you are talking to the right server.

    Trusting in CAs either gives you an "E-Mail tax" where you give money to a company for a certificate, or it creates a centralized single point of failure by using "Let's Encrypt".

    In any case, lifting the task of an attacker from simple sniffing to an active attack is already rather good. Realistically the next step would be to shake out all the missfeatures and bug out of TLS since that has, in recent years, been proven to be a far more problematic problem. (see Heartbleed)

  6. jMcPhee

    Google, Yahoo, and Microsoft can read the mail...

    ...and that's probably a bigger worry. Not to mention, the TLA's. And, who cares that travel or penis spam is securely sent?

    If it's that big a deal, there's always user level encryption. Sorry, EFF, I'm not with you on this one.

  7. chroot

    Implicit TLS

    Is this a new discussion between Implicit TLS and STARTTLS? The IETF recommended as recently as in February to ditch STARTTLS and use Implicit TLS.

    https://www.theregister.co.uk/2018/02/01/ietf_attacks_cleartext_email/

    1. alanjmcf

      Re: Implicit TLS

      No, if I read it correctly, that’s about client-server interactions (IMAP, SMTP-Submission), not server-server connections (SMTP) as this is.

  8. Joe Harrison

    Could have been worse

    I spent years supporting various X.500 email services which were supposed to be far superior to your noddy smtp delivered over uucp. It never went anywhere much though.

    I had got used to using email at work and when I saw redundancy coming up I shopped around for some kind of personal email account, which were rare in the 1990s. BT had one, which was X.500, but in addition to a standing charge it cost 40p per message! Luckily Demon tenner-a-month came along just at the right time.

  9. druck Silver badge
    Flame

    PlusNet 10 years of FAIL

    PlusNet are still refusing to implement STARTTLS a decade after every decent ISP adopted it.

  10. streaky

    DNS

    since most DNS requests are still unauthenticated (see the section on DANE above), an active attacker can still man-in-the-middle the initial DNS request and convince the sender that the recipient doesn’t support MTA-STS

    That might be true, is in fact, I've spoken about it here and elsewhere a number of times but a unified solution is going to be messy. Personally I think there's a number of protocols we should be looking again at and the email ones especially are part of this - like how we guarantee jurisdiction if security services come with warrants - but you can't solve all of this in one go. You really have to let DNS security be DNS security and email security be email security and then pin mail server auth to dns. We've seen from PGP how messy solutions don't solve the problem. The problem is MITM from otherwise well configured servers.

    Offer me the protocols and if I believe I need more secure email transport I'll use it.

  11. GnuTzu
    Unhappy

    There Are Times and Situations...

    I've seen places gambling on STARTTLS when VPN's would have been the correct solution. These are the cases when you need to be absolutely sure that certain email is never traversing the Internet un-encrypted. A VPN would never (cross fingers) allow traversal without en-cryption, and would simply fail to transfer anything if down. But, if your mail configuration gets borked, how long before you figure out that you've been passing sensitive data in the clear. Since encountering the problem some years ago, I've had the same negative feelings about SFTP.

  12. J. Cook Silver badge
    Trollface

    Well, if forcing in-transit encryption is unfeasible...

    ... Can we get people working on making userland message encryption easier to use? (I tried getting pgp to work with a standard pop3 account many many years ago; not only did it not work, but the attempt was a total nightmare to try and install and configure. your average Joe User is probably going to want a ticky box that says "encrypt this message" and lets the program do the rest.)

  13. EnviableOne

    Security As An Afterthought

    THe problem with <insert internet technology here> is the original ArpaNet was built between parties that trusted each other implicitly, so no security was required.

    The problem we have now is World+Dog are on tinternet and No-one knows who to trust, and tacking on security afterwards is allways a bad idea. The alternative (rebuild the internet with security from the ground up, is not to palletable either

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like