EFF Announces STARTTLS Everywhere To Help Make Email Delivery More Secure (betanews.com) 58
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.
This doesn't help man-in-the-middle attacks (Score:3)
Since you can just make it appear that TLS is unavailable.
Re:This doesn't help man-in-the-middle attacks (Score:5, 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.
Re: (Score:1)
Apple could break mass surveillance at a stroke by integrating S/MIME certs into its AppleID generation process. They could automate the S/MIME cert issuance process (even letting the user pick a certification agency) and then use what's already baked-in to macOS and iOS to automagically attempt to encrypt all mail. Apple has a knack for simplifying things to the point your mother could use it without worry: they could make a huge swath of the e-mail ecosystem suddenly very time-consuming for the NSA.
Re: (Score:2)
This is a good thing. This is an attempt to break mass surveillance.
No, it's stupid.
Doing SMTP over TLS was effective. If TLS support isn't widespread, that is what should be fixed.
Why are we wasting time implementing an optional standard that is weaker---and completely vulnerable to MITM attacks?
Re: (Score:3)
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 whe
Re: (Score:2)
Re: (Score:2)
We might think this is an issue for Google or the other big email aggregators, and we might see it somewhat an issue for big corporate, and there's a slight possibility it will affect moderately sized entities, but for the majority which is what we really should be considering that's not an issue.
Re: (Score:2)
Re: (Score:2)
I'm being facetious but...do you mean there are sites that are passing email over port 25 instead of using tls over port 465? Yeah I've heard that 465 isn't a standard and was used briefly but it does work. Starttls on port 587 works but I'd like to see a mandate where everyone is force to use tls.
Re: (Score:1)
This raises the effort required from passive snooping to active interception. This is a good thing. This is an attempt to break mass surveillance.
It doesn't raise the effort at all. Most ISPs are already using Cisco PIX-like appliances that intercept SMTP traffic on tcp/25 and filter out the STARTTLS keyword from the SMTP server's Greeting response. They are then free to log the rest of the SMTP conversation and/or pipe it through to their favourite 3-letter agency.
The only way this effort is going to make any traction is if mail clients start requiring STARTTLS by default - and that users are educated enough to take their ISPs to task for attempting
Re:This doesn't help man-in-the-middle attacks (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.
This is weak. (Score:5, 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."
Re: (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.
Re: (Score:2)
While this isn't far-fetched, at least it would require the client or MTA to ignore a failed TLS handshake. With certificate pinning, it's about as good (or bad) as what SSH does (learning a host key on first use, later complaining if it changes)
Re: (Score:2)
That's trivially avoidable by man-in-the-middle -- the attacker will kindly accept unencrypted connections to you, and upgrade to TLS for the second hop.
Re: (Score:2)
I'm not sure if removing the plaintext listener solves the issue, since the MITM operator has prevented you from reaching it anyway.
I wonder if this is something that can be dealt with by an extension to SPF. Where if you advertise STARTTLS then servers can check that, and refuse to deliver to your MX host if STARTTLS is not actually available when they try to connect.
Of course that requires that the DNS also be signed/secure. :) But with that in place MITM would be a lot harder.
this is good enough for most people (Score:1)
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.
Except that currently, with completely clear-text SMTP transactions, surveillance departments can tap glass and do a wholesale capture of all e-mail traffic over a network hop.
If, however, everyone starts using STARTTLS then the three-letter agencies have to start expending resources to MITM all those various connections. This is much more difficult than simply slurping up bits.
For most people this is good enough. If you're on the government's radar chances are you're fucked when it comes to being monitorin
Re: (Score:2)
Except that currently, with completely clear-text SMTP transactions, surveillance departments can tap glass and do a wholesale capture of all e-mail traffic over a network hop.
If, however, everyone starts using STARTTLS then the three-letter agencies have to start expending resources to MITM all those various connections. This is much more difficult than simply slurping up bits.
Yes, good point.
The choice is not: 0% security for everyone (plain SMTP) or 100% security for everyone (S/MIME, PGP). Opportunistic encryption is on the sliding scale of giving many people 10/20/40/80/whatever-percent security, all of which is better than 0.
Sure. But keep in mind this is just an EFF recommendation, as far as I understand it. So in and by itself, it doesn't make anybody enable anything. Since this is still dependent on admins (and MUA developers) taking action, they might as well have recommended to go for unconditional SMTPS instead of STARTTLS.
Re your follow up comment, I fail to see how "You have to use STARTTLS with this MTA" is any different (except in that it still allows a MITM to briefly mess with the connection) from
Re: (Score:2)
Re: (Score:2)
So what's the difference between unconditional STARTTLS and SMTPS, other than the former opening up a brief opportunity for a MITM to mess with the connection?
Re: (Score:3)
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.
Re: (Score:2)
Ok, but Joe Sixpack doesn't.
Plus this is hop-to-hop, you only get to control whether or not to talk to the first hop, after than all bets are off. Let's hope all MTAs in the chain are configured the same way?
I applaud the EFF for enforcing strong security (Score:1)
See subject: Finally we get STARTTLS and hop-to-hop encryption technology.
Safety at last.
APK
P.S.: EFF all the way! ...apk
Re: (Score:2)
Hosts Files (Score:2, Funny)
Re: (Score:1)
Too late, he's already been summoned.
Kill it with fire (Score:3)
Re: (Score:1)
> 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.
You must not be sending/receiving much mail then! About half of providers in my case, especially newsletter mailers, do not support any of it and all such mails bounce. Then you get the 'Your email doesn't work' infos via other channels, even though it's their provider wit
STARTTLS has been SOP for years (Score:1)
STARTTLS has been standard operating procedure since we found out the NSA was a bad actor ten years ago. It's a central feature of every mail transfer agent. Other than spam most email uses it, and has for a long long time.
hop-to-nsa-to-hop encryption - fixed that for you (Score:2)
Yes, of course (Score:2)
We want an ecosystem that encourages and allows choice... and then decide to force certain choices down you your throat.
wait... what?!
In general, I support the EFF. When this sort of fundamentalist thinking mode takes hold, the end is NEVER good, no matter how well intentioned.
If sponsoring Let's Encrypt means selling certs (Score:2)
Is the EFF trying to sell certificates now?
Not quite, but Electronic Frontier Foundation is sponsoring the Let's Encrypt CA. In addition, many of the same companies sponsor both EFF (source [eff.org]) and LE (source [letsencrypt.org]). Fastly and DigitalOcean, for example, sponsor both organizations.
once negotiated it prevent interception of the message being TRANSPORTED over the network. In order to do this self-signed certificates are perfectly adequate.
"Negotiation" of a TLS connection includes the client accepting the certificate that the server presents. This is fine over a LAN, as (say) a printer can write the fingerprint of its self-signed certificate to paper in text and QR code form, or a home server appliance can use a com
Re: (Score:2)
See RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
This is a solved problem. You just need to use the solution.
DNSSEC is an upsell at some popular registrars (Score:2)
DANE requires DNSSEC, and adoption of DNSSEC requires domain name registrars and DNS zone hosts to make it cheap and easy. Right now many don't. For example, last I checked, GoDaddy considered DNSSEC to be a "premium" feature not included in the zone hosting bundled with registration. I'd assume this is to discourage use of DANE in favor of GoDaddy's CA, but I'm interested in defenses of why this is mere incompetence on GoDaddy's part.
junk (Score:2)
What's the point of a half-assed solution when a full ass exists? This will only serve to marginalize full end-to-end encryption. Did NSA pay for this one?
Re: (Score:1)
Na this still helps. Even with fully encrypted email there would still be a lot of meta data that could be monitored without accessing the mail servers. This will cut that down. I'm sure the eff would be interested in the end to end encryption eventually as well.
If only... (Score:2)
If only there was a unified protocol for creating encrypted sessions between systems for all IP packets.