Slashdot Mirror
EFF Announces STARTTLS Everywhere To Help Make Email Delivery More Secure (betanews.com)
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.
Since you can just make it appear that TLS is unavailable.
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!
See subject: Finally we get STARTTLS and hop-to-hop encryption technology.
Safety at last.
APK
P.S.: EFF all the way! ...apk
Another layer to use is to add support for Hosts Files. There is a Host File engine that I recommend that is fast and secure.
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.
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 - why do half steps?
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 monitoring, but by scrambling all traffic at least innocent people aren't caught in the cross fire of governments monitoring for nefarious activities.
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.
Perfect is the enemy of good (enough).
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.
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) and LE (source). 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 composite, VGA, or HDMI output or a built-in status LCD to display the fingerprint. But it's less fine at Internet scale unless there's some convenient means of out-of-band communication between the operators of the client and the server. How would it be practical for every MTA operator to verify every other MTA's self-signed certificate through out-of-band communication?
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?
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.
If only there was a unified protocol for creating encrypted sessions between systems for all IP packets.