|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
18 Nov 2015, 02:33 AM | #1 |
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, 03:00 AM | #2 |
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, 03:21 AM | #3 | |
Cornerstone of the Community
Join Date: Jun 2004
Posts: 743
|
Quote:
http://blog.fastmail.com/2009/04/16/...coming-emails/ |
|
18 Nov 2015, 10:30 AM | #4 |
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:
|
18 Nov 2015, 10:40 AM | #5 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,930
|
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 |
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 |
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.
|
20 Nov 2015, 12:52 AM | #8 |
The "e" in e-mail
Join Date: Feb 2006
Location: EU
Posts: 4,945
|
|
20 Nov 2015, 01:48 AM | #9 |
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
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. Last edited by jhollington : 20 Nov 2015 at 01:54 AM. |
20 Nov 2015, 04:52 AM | #10 | |
Master of the @
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007
Representative of:
Fastmail.fm |
Quote:
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? |
|
25 Nov 2015, 11:53 PM | #11 | |
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
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. |
|
26 Nov 2015, 10:09 AM | #12 |
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 |
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 |
29 Dec 2015, 05:05 PM | #14 | |
Cornerstone of the Community
Join Date: Mar 2011
Location: ~$
Posts: 652
|
Quote:
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. |
|
3 Jan 2016, 07:43 AM | #15 |
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? |