Tony Finch - Security error in GMail's TLS setup

dotatfanf wrote
on 6th June 2012 at 20:50
Previous Entry Share Next Entry

Security error in GMail's TLS setup

RFC 6186 specifies how to use SRV records to auto-configure an MUA given an email address. There is an error with the setup of GMail's RFC 6185 SRV records which means that a correctly implemented client will fail to connect, reporting a certificate mismatch / security failure.

The SRV records are:

  _submission._tcp.gmail.com. 84664 IN  SRV   5 0 587 smtp.gmail.com.
  _imaps._tcp.gmail.com.      84628 IN  SRV   5 0 993 imap.gmail.com.
  _pop3s._tcp.gmail.com.      86400 IN  SRV  20 0 995 pop.gmail.com.

These servers all present certificates that only authenticate the corresponding SRV target host name - they do not contain any SubjectAltName fields for gmail.com. They also do not support Server Name Indication to vary their certificate according to the name expected by the client. The gmail.com zone is not signed with DNSSEC.

RFC 6186 says that certificate verification follows the procedure set out in RFC 6125. The relevant part is RFC 6125 section 6.2.1. In particular,

Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain).
That is, the only acceptable reference identifier for an RFC 6128 client that has been given a gmail.com address is gmail.com. This does not match the identifiers in any of the certificates.

This error is not a security vulnerability in itself, though it can lead to vulnerabilities when combined with human factors, such as:


(Leave a comment)
From:(Anonymous)
Date:2012-06-07 00:50 (UTC)
(Link)
Sadly, Mozilla Thunderbird still hasn't implemented RFC 6186 (https://bugzilla.mozilla.org/show_bug.cgi?id=342242), so there is no pressure on Google (Instead Mozilla added support for uploading files to YouSendIt (https://wiki.mozilla.org/Features/Thunderbird/BigFiles) and their own automatic configuration protocol (https://wiki.mozilla.org/Thunderbird:Autoconfiguration)). However, there have been first steps implement support for SRV records (https://bugzilla.mozilla.org/show_bug.cgi?id=735967) and thus (probably in a couple of years) for RFC 6186.
(Reply) (Thread)
From:syscomet
Date:2012-06-07 17:30 (UTC)

Customers

(Link)
Remember that Google Apps for your Domain means that every GAfyD customer potentially also has such SRV records and that gmail.com is, from that perspective, "just another" domain. Without DNSSEC, they're just in the same situation as every other customer.

If it's anything like the situation with XMPP, it just means that clients special-case the Google servers. :(
(Reply) (Thread)
From:mas90
Date:2012-06-15 02:11 (UTC)
(Link)
I see why the spec had to constrain verification in this way - on a non-DNSSEC zone you can't trust any derived domain - but from my perspective this makes RFC 6186 almost entirely useless. I don't want to have to get a new certificate for each of my mail servers every time I start to host a new domain.

Quite apart from the administrative effort involved, this would be rather expensive. Maybe DANE will help with the latter, although if you have DANE you have DNSSEC and the problem that RFC 6125 section 6.2.1 is solving disappears in the presence of DNSSEC anyway.
(Reply) (Thread)
From:mas90
Date:2012-06-15 02:18 (UTC)
(Link)
(And for what it's worth, the autoconfiguration protocol used by Thunderbird, Evolution, etc. doesn't have this problem - although come to think of it, since it uses unencrypted HTTP, it can be MITMed and made to send your password to any server without warning. Hm. I wonder whether anyone told Mozilla.)
(Reply) (Parent) (Thread)

(Leave a comment)

Powered by LiveJournal.com