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 …
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.
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 (-;
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.
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.
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.
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.
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)
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.
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.
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.
... 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.)
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
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
