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
nt
--sf
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).
Yeah, this is better than a kick in the shin, but I was hoping this was talking about a way to actually tackle email encryption.
In addition to my above comment, the IETF is working on SMTP MTA Strict Transport Security (MTA-STS):
SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
* https://tools.ietf.org/html/draft-ietf-uta-mta-sts
So even if someone tries to MITM, the the sending MTA knows it should send over TLS and will refused to be fooled.
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.
hop-to-nsa-to-hop encryption - why do half steps?
You're only half joking, but any bad actor with the ability to modify your DNS zone can publish a MX record with higher priority (lower MX score) than your primary MX. Their fake MX can easily just forward to the real MX and the target would be largely no wiser.
Doesn't require that the attacker gets MITM on the direct path to your MX, doesn't require fake certificates because their fake MX has a real hostname - letsencrypt will happily provide it valid certs. For most targets, very low chance of being caught out - who checks their MX logs to ensure a good distribution of source IPs and who regularly checks their DNS zone for accuracy?
It's the kind of attack that a nation state could pull off against a user in a different nation state so long as the DNS registrar does business in both states and I wouldn't be surprised to learn it's already been done.
STARTTLS is Start Transport Layer Security. It is not an "authentication" protocol, merely an encryption protocol. Is the EFF trying to sell certificates now?
TLS with self-signed certificates is perfectly adequate and does exactly that which it portends doing, provide "TRANSPORT LAYER SECURITY". That is, once negotiated it prevent interception of the message being TRANSPORTED over the network. In order to do this self-signed certificates are perfectly adequate.
Because cost can never go as low as it needs to provide a free service.
This post about a groundbreaking tech innovation has less than 40 comments while some loony posting about Trump and Russia garbage or 'global warming' gets hundreds of garbage.
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?
I opened an account with the online bank Ally a few years ago. When I moved, I changed my address for my online account. But then to my surprise, Ally Bank held my money hostage until I proved that I was the one who logged into my account and changed my address!
In order to unlock my account (and my money), Ally Bank's customer "service" rep told me I would have to email a scan of my driver license or passport. I immediately responded, "NO!" I told him that was a very bad thing for any company to ask a customer to do, since email is unsecure, and it could expose my identity over the open Internet to identity thieves. The Ally Bank rep then assured me that Ally Bank's "email servers are very secure"!!!
WTF?
Ally Bank did not seem to realize that no matter how "secure" an email server may be, it is the transmission of emails unencrypted over the open Internet that was the extremely weakest link. I finally ended up sending Ally Bank a copy of my driver license through the postal mail. Then I closed my account with Ally Bank as fast as I could.
Moral: companies like Ally Bank do not realize that traditional email protocols themselves are unsecure, regardless of whether email servers (or clients) are secure.
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?
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.
For anyone who thinks it's a step in the right direction, let me explain hop to hop encryption:
Hop to hop (STARTTLS) is like when you write a letter, put it in an envelope, and give it to the mailman. The mailman then takes the letter out of the envelope and reads it. Just before giving it to the recipient, the mailman puts the letter into a new envelope.
If the mailman delivering the mail is not the same mailman who collected it, the first mailman may or may not put the letter in yet another envelope that the second mailman will then take it out of.
If this seems stupid, you probably understood it.
End to end encryption is when you put the letter into an envelope and the mailman delivers the envelope with contents without opening it (as long as the encryption isn't broken, he can't open it).
ARE YOU LOOKING FOR A ONLINE HACKERS, FRIENDS DARE. IF YOU NEED GENUINE AND PROFESSIONAL HACKING SERVICES CONTACT spymasterpro3x AT gmail dot com via the google mail address. They are professional group of hackers based on their worldwide clientele, Europe, Asia, United Arab Emirates, North America. They are the best hackers and software developers to penetrate any website, all other hackers get in touch with them to get the best Algorithm software. Their services are 100% guaranteed also with their penetration software impossible to track. spymasterpro3x atgmail dot com offer top notch hacking services.
This is a stupid waste of time. It provides a false sense of security to clueless admins and especially to users and PHBs.
They need to work on end-to-end email encryption adoption. Hop-to-hop is pointless! Any hop can be inserted and you have no control over it. Email cannot ever be secure until the actual message is encrypted.
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.