Log in

No account? Create an account


Security error in GMail's TLS setup

« previous entry | next entry »
6th Jun 2012 | 20:50

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:

  • Users of RFC 6186 clients might turn off certificate verification for gmail.com in order to make connections work.
  • Authors of RFC 6186 clients might copy the same mistake for interop purposes and write code match certificates against insecurely derived identifiers (SRV target hostnames in non-DNSSEC zones).

| Leave a comment |

Comments {4}

from: anonymous
date: 7th Jun 2012 00:50 (UTC)

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: 7th Jun 2012 17:30 (UTC)

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: 15th Jun 2012 02:11 (UTC)

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: 15th Jun 2012 02:18 (UTC)

(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