STARTTLS downgrade attacks

gareth · 18 Nov 2015, 02:33 AM

According to
https://www.eff.org/deeplinks/2014/1...ngrade-attacks

"Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the US and Thailand intercepting their customers' data to strip a security flag—called STARTTLS—from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.1

By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted [...]"

I thought STARTTLS was between client and server and that all transmission of email between servers/relays was in plaintext anyway (or unadulterated transmission of that which has already been encrypted via PGP etc)... no?

If someone could clarify I'd be grateful

Thanks
G

gareth · 18 Nov 2015, 03:00 AM

Looks like it's optional (and not guaranteed end-to-end) between MTAs?

https://www.ietf.org/rfc/rfc3207.txt

placebo · 18 Nov 2015, 03:21 AM

Quote:

Originally Posted by gareth

I thought STARTTLS was between client and server and that all transmission of email between servers/relays was in plaintext anyway (or unadulterated transmission of that which has already been encrypted via PGP etc)... no?

No, it can also be between servers. FastMail had a blog post about implementing this back in 2009.

http://blog.fastmail.com/2009/04/16/...coming-emails/

BritTim · 18 Nov 2015, 10:30 AM

Unless using end-to-end encryption, email traffic should be assumed vulnerable to snooping. That said, it is important to appreciate that we are talking about two separate issues with a STRIPTLS attack:

An attempt can be made to convince your email client that the SMTP server you use (mail.messagingengine.com in the case of FM) does not support TLS, in an effort to convince the client to transmit the entire session in plaintext. Were this to succeed, it would expose user/password information as well as the email itself. However, FM is not vulnerable.
When Fastmail is relaying outgoing email to recipient mail servers, it will try to use opportunistic encryption to protect server-to-server communication. FM can be fooled into transmitting messages in plaintext (allowing snooping) if the fact that the remote server supports TLS is hidden by a man-in-the-middle attack. The solution, which will gradually be implemeted, is to maintain a list of servers supporting TLS and ignore the TLS flag during session initialization.

n5bb · 18 Nov 2015, 10:40 AM

That blog entry was with respect to incoming connections to Fastmail servers from other email services. Fastmail has also implemented opportunistic outgoing secure connections for nearly six years:
http://blog.fastmail.com/2010/01/29/...tgoing-emails/

These incoming and outgoing encryption events are opportunistic because some email systems don't support this encryption. So if you exchange an email to or from some other service whose servers don't support encryption, your message will be handled in a non-encrypted transfer. You can usually determine if the received message was delivered via an encrypted connection by examining the full headers and looking for using TLS in the first received header when your email provider receives the message from the sending system.

Fastmail has forced their users to use encrypted connections for over three years:
http://blog.fastmail.com/2012/07/16/...p-connections/

Bill

jhollington · 20 Nov 2015, 12:44 AM

This is also when I've setup email systems in the past I've frequently only used servers/gateways that allow the listing of domains for key partners/clients (many of my customers have been law firms) for which TLS is required.

It would be nice if FastMail could provide an interface – especially for business accounts – to allow this kind of TLS enforcement – basically, only allow the transmission of an email message is a TLS session can be established with the target server, otherwise defer and/or fail the delivery.

jhollington · 20 Nov 2015, 12:46 AM

Note that there are also sites that allow you to check if an email address at a given domain supports TLS, and if it's configured properly (e.g. all of the valid and matching certificate chains in place). I personally use CheckTLS.com for this, but I'm sure there are others out there as well.

janusz · 20 Nov 2015, 12:52 AM

Quote:

Originally Posted by jhollington

there are also sites that allow you to check if an email address at a given domain supports TLS, and if it's configured properly.

And what do you do if the address/domain fails the test?

jhollington · 20 Nov 2015, 01:48 AM

Quote:

Originally Posted by janusz

And what do you do if the address/domain fails the test?

Well, if it's yours, you fix it or change providers to somebody who does support TLS properly (like FastMail

).

If it's somebody else's, there's not really much you can do. If it looks like they've tried to support TLS but something is broken, you could try to find an administrator for the domain and let them know (addresses like "admin", "administrator", and "postmaster" frequently work).

However, if they just haven't configured it at all, then unless you can either convince the administrator of the mail system to set it up properly or the person you're sending to to change providers, you're just going to have to accept the fact that any mail you send to that domain will travel between FastMail and the target domain in the clear (or stop sending at least certain emails to them if you're concerned about the security of it

). Keep in mind that none of this will expose things like passwords (unless you're sending passwords in the body of your email messages). Anything you submit to FastMail's servers will still be encrypted, but it will just be sent unencrypted between FastMail's sending SMTP server and the recipient's receiving mail server. It's even possible that the recipient will receive the email over an encrypted connection (IMAPS, POPS, or HTTPS-secured webmail), but it's impossible to know that for certain.

Another option of course would be to encrypt the mail client-side – then it's secure against any kind of snooping even at rest on servers. The downside of course is that it requires participation of the recipient, and if they care enough to implement something like S/MIME or PGP, then they'd likely be on a TLS-compliant provider anyway.

Honestly, though, with TLS support being pretty much standard now and just about every major mail provider supporting it, there's little excuse for being on a provider who doesn't.

It's also important to keep in mind that SMTP-level encryption (STARTTLS) only encrypts mails in transit, not at rest. Messages that live on intermediate mail relays will likely still be stored in the clear as well, at least for as long as it takes to send them to the next hop or deliver them to the final destination mail store.

robn · 20 Nov 2015, 04:52 AM

Quote:

Originally Posted by jhollington

This is also when I've setup email systems in the past I've frequently only used servers/gateways that allow the listing of domains for key partners/clients (many of my customers have been law firms) for which TLS is required.

It would be nice if FastMail could provide an interface – especially for business accounts – to allow this kind of TLS enforcement – basically, only allow the transmission of an email message is a TLS session can be established with the target server, otherwise defer and/or fail the delivery.

"Enforcing TLS" between servers is kind of fuzzy. You can force the channel to be encrypted, but almost no-one does certificate verification, so you still have no guarantee that you're actually connected to the correct site. A small but significant number of sites use self-signed certificates for this reason - there's not much to be gained by buying a "trusted" cert.

And no, we can't make a hypothetical "enforce" option verify the cert, because there's nothing to check it against. On the web, you go to a domain, and you check that the cert matches that domain. If any part of the process is intercepted, the check will fail.

For mail, there's a weak link in the trust chain - the DNS. If I'm sending to @fastmail.com, first I have to look up the MX record for fastmail.com (in1-smtp.messagingengine.com), then I connect to in1-smtp and issue STARTTLS and send the message. If the DNS is being attacked (poisoned, MITM) and the MX lookup returns, say, mx.badsite.com, I'll connect there instead, They may have a perfectly valid certificate for *.badsite.com, so I'll never know that I'm actually in the wrong place.

The solution to this a thing called DANE, where fastmail.com publishes a signed (ie DNSSEC) record with the certificate fingerprint for in1-smtp. The client can then check if it landed at the wrong place. This would work well, except that DNSSEC is still not widely deployed (yes, I know we're to blame here too, we're getting there!). Unfortunately, for some ccTLDs (including .fm), DNSSEC is not available at the registry, so we have no solution at all there.

(there's a great writeup of everything I just said at https://blog.filippo.io/the-sad-stat...tp-encryption/).

So given all of that, I'm really curious as to what the "required TLS" from the setup you mention actually enforces. Is it just an encrypted channel, or full trust? What kind of attacks were they hoping to protect against?

jhollington · 25 Nov 2015, 11:53 PM

Quote:

Originally Posted by robn

So given all of that, I'm really curious as to what the "required TLS" from the setup you mention actually enforces. Is it just an encrypted channel, or full trust? What kind of attacks were they hoping to protect against?

The primary objective in almost all of these cases has generally been to ensure confidentiality of data, and you're right that the trust chain can be easily broken in a typical TLS implementation, but in the more simple implementations it was always considered "good enough" based on the relatively low probability of a compromised set of DNS records.

However, in many cases it was also a matter of using TLS to replace previous proprietary encryption gateways that some of these organizations used in the years before TLS moved into more widespread use. In some cases these were dedicated gateways, in other cases it was systems like Novell GroupWise and its "dynamic Internet link" MTA-to-MTA transfers over port 7100 (facilitated using "gwmtp" SRV records). Obviously with the evolving Internet, more and more companies have wanted to move to open standards rather than their own proprietary technologies (the same reason, IMHO, that client-side encryption technologies like PGP and even S/MIME have never gained traction).

When dealing with known communication channels (established partner/client systems), one of the strategies has been to basically create quasi-dedicated secure channels by hardcoding target mail server names. At that point, the trust chain is based not on the MX records for @somedomain.com by rather on the specific A record for the target mail server, which of course can more easily enforce a certificate match. The call here was that encryption and certificate verification was more important than mail deliverability – if MX records change, the A records on the outbound mail gateway would be updated manually.

In fact, at least two of the major banks up here that I've dealt with offer dedicated "secure mail gateways" for their business partners, different from their published MX records, that refuse all non-TLS, non-verified inbound connections. While these server names are published in DNS of course, they're not otherwise available to the public -- you basically have to know the server name to use them, and they're pretty draconian in their enforcement of certificate validation.

robn · 26 Nov 2015, 10:09 AM

Thanks for the info. That's about what I expected, to be honest.

I think if I were to do it I'd make it so you could associate a domain with a key fingerprint, and only send to it if the fingerprint matched. That way the user gets control of it, and the remote server can continue to use a self-signed cert or whatever else it wants to do.

Its such a specialised feature though I'm pretty sure its not something we'll ever end up doing. I will keep it in the back of my head for when we eventually do DANE, since its mostly just a second source of key fingerprints (though slightly complicated by being per-user).

nachoig · 29 Dec 2015, 02:28 PM

Excuse me, but is DANE really the solution? I'm seeing some articles saying it doesn't fix those issues.

https://www.imperialviolet.org/2015/01/17/notdane.html
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://ianix.com/pub/dnssec-outages.html

kijinbear · 29 Dec 2015, 05:05 PM

Quote:

Originally Posted by nachoig

Excuse me, but is DANE really the solution? I'm seeing some articles saying it doesn't fix those issues.

https://www.imperialviolet.org/2015/01/17/notdane.html
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://ianix.com/pub/dnssec-outages.html

A lot of those arguments would have applied perfectly well to good old HTTPS only a few years ago, and yet we're entering the age of nearly universal HTTPS adoption, at least on websites where privacy matters. Moreover, nobody seems to be too worried about the feasibility of requiring ever more stringent checks on HTTPS, such as not allowing 1024-bit keys, banning SHA-1 signatures, not supporting SSLv3, etc. If someone can't access a modern website using IE6 on Windows XP, it's their problem, not ours. If all the existing CAs are crappy, just start a better one that is much more resistant to known attacks. (For example, Let's Encrypt verifies domains from multiple locations to combat MITM attacks.)

The tech industry's collective experience with HTTPS over the last few years will probably lead people to change their attitudes when it comes to other security-related issues. "But it needs to be compatible with 20-year-old programs!" will no longer be a good excuse anymore. Early adoption and constant improvement should become the norm, rather than waiting for a single perfect standard to appear and then settling on it for the next 20 years.

Or at least I hope that that's what happens with DANE. Is it the solution? Of course not! The only solution is to start with whatever tools we've got and improve it over time. Security is an arms race. Whoever stops innovating loses.

nachoig · 3 Jan 2016, 07:43 AM

But their arguments are plausible, specially about who controls the TLDs and a lot of those TLDs don't work with modern cryptography signatures.

About e-mail specifically, I have the impression the issue here is because SMTP accepts absolutely anything as valid instead of saying "present a valid and trusted (aka not self-signed) certificate against the original domain portion of the e-mail address or GTFO."

It would be interesting to compare this against the XMPP situation. BTW, FastMail has a XMPP service. Every time I try to connect to it, I receive an alert from Jitsi claiming the certificate presented is only valid against chat.messagingengine.com, but not against fastmail.fm. Why the e-mail clients don't complain in cases like this?

18 Nov 2015, 02:33 AM	#1
gareth Senior Member Join Date: Mar 2002 Location: UK Posts: 190	STARTTLS downgrade attacks According to https://www.eff.org/deeplinks/2014/1...ngrade-attacks "Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the US and Thailand intercepting their customers' data to strip a security flag—called STARTTLS—from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.1 By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted [...]" I thought STARTTLS was between client and server and that all transmission of email between servers/relays was in plaintext anyway (or unadulterated transmission of that which has already been encrypted via PGP etc)... no? If someone could clarify I'd be grateful Thanks G

18 Nov 2015, 10:30 AM	#4
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,095	Unless using end-to-end encryption, email traffic should be assumed vulnerable to snooping. That said, it is important to appreciate that we are talking about two separate issues with a STRIPTLS attack: An attempt can be made to convince your email client that the SMTP server you use (mail.messagingengine.com in the case of FM) does not support TLS, in an effort to convince the client to transmit the entire session in plaintext. Were this to succeed, it would expose user/password information as well as the email itself. However, FM is not vulnerable. When Fastmail is relaying outgoing email to recipient mail servers, it will try to use opportunistic encryption to protect server-to-server communication. FM can be fooled into transmitting messages in plaintext (allowing snooping) if the fact that the remote server supports TLS is hidden by a man-in-the-middle attack. The solution, which will gradually be implemeted, is to maintain a list of servers supporting TLS and ignore the TLS flag during session initialization.

18 Nov 2015, 03:00 AM	#2
gareth Senior Member Join Date: Mar 2002 Location: UK Posts: 190	Looks like it's optional (and not guaranteed end-to-end) between MTAs? https://www.ietf.org/rfc/rfc3207.txt

18 Nov 2015, 10:40 AM	#5
n5bb Intergalactic Postmaster Join Date: May 2004 Location: Irving, Texas Posts: 8,929	That blog entry was with respect to incoming connections to Fastmail servers from other email services. Fastmail has also implemented opportunistic outgoing secure connections for nearly six years: http://blog.fastmail.com/2010/01/29/...tgoing-emails/ These incoming and outgoing encryption events are opportunistic because some email systems don't support this encryption. So if you exchange an email to or from some other service whose servers don't support encryption, your message will be handled in a non-encrypted transfer. You can usually determine if the received message was delivered via an encrypted connection by examining the full headers and looking for using TLS in the first received header when your email provider receives the message from the sending system. Fastmail has forced their users to use encrypted connections for over three years: http://blog.fastmail.com/2012/07/16/...p-connections/ Bill

20 Nov 2015, 12:44 AM	#6
jhollington Essential Contributor Join Date: Apr 2008 Posts: 371	This is also when I've setup email systems in the past I've frequently only used servers/gateways that allow the listing of domains for key partners/clients (many of my customers have been law firms) for which TLS is required. It would be nice if FastMail could provide an interface – especially for business accounts – to allow this kind of TLS enforcement – basically, only allow the transmission of an email message is a TLS session can be established with the target server, otherwise defer and/or fail the delivery.

20 Nov 2015, 12:46 AM	#7
jhollington Essential Contributor Join Date: Apr 2008 Posts: 371	Note that there are also sites that allow you to check if an email address at a given domain supports TLS, and if it's configured properly (e.g. all of the valid and matching certificate chains in place). I personally use CheckTLS.com for this, but I'm sure there are others out there as well.

26 Nov 2015, 10:09 AM	#12
robn Master of the @ Join Date: May 2012 Location: Melbourne, Australia Posts: 1,007 Representative of: Fastmail.fm	Thanks for the info. That's about what I expected, to be honest. I think if I were to do it I'd make it so you could associate a domain with a key fingerprint, and only send to it if the fingerprint matched. That way the user gets control of it, and the remote server can continue to use a self-signed cert or whatever else it wants to do. Its such a specialised feature though I'm pretty sure its not something we'll ever end up doing. I will keep it in the back of my head for when we eventually do DANE, since its mostly just a second source of key fingerprints (though slightly complicated by being per-user).

29 Dec 2015, 02:28 PM	#13
nachoig Junior Member Join Date: Dec 2014 Posts: 15	Excuse me, but is DANE really the solution? I'm seeing some articles saying it doesn't fix those issues. https://www.imperialviolet.org/2015/01/17/notdane.html http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://ianix.com/pub/dnssec-outages.html

3 Jan 2016, 07:43 AM	#15
nachoig Junior Member Join Date: Dec 2014 Posts: 15	But their arguments are plausible, specially about who controls the TLDs and a lot of those TLDs don't work with modern cryptography signatures. About e-mail specifically, I have the impression the issue here is because SMTP accepts absolutely anything as valid instead of saying "present a valid and trusted (aka not self-signed) certificate against the original domain portion of the e-mail address or GTFO." It would be interesting to compare this against the XMPP situation. BTW, FastMail has a XMPP service. Every time I try to connect to it, I receive an alert from Jitsi claiming the certificate presented is only valid against chat.messagingengine.com, but not against fastmail.fm. Why the e-mail clients don't complain in cases like this?