Why don't Google's MX servers match the SSL certificate CN? - ssl

Question

Before sending an email to a google account my script looked up the MX records for google's email servers. The results are:
gmail-smtp-in.l.google.com
alt1.gmail-smtp-in.l.google.com
alt2.gmail-smtp-in.l.google.com
alt3.gmail-smtp-in.l.google.com
alt4.gmail-smtp-in.l.google.com
I then successfully connected to gmail-smtp-in.l.google.com and after EHLO I started a STARTTLS request to switch to SSL. However, I set the script to check and make sure the host(s) listed in the certificate match the domain I was connecting too.
stream_context_set_option($fh, 'ssl', 'CN_match', 'gmail-smtp-in.l.google.com`);
However, this is where things break. I got the following error:
stream_socket_enable_crypto(): Peer certificate CN='mx.google.com' did not match expected CN='gmail-smtp-in.l.google.com'
I checked to find out where nslookup mx.google.com was located and found it doesn't exist.
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find mx.google.com: NXDOMAIN
Why doesn't the SSL certificate match the domains using it? Am I missing something?
The following is the cert my script received from them.
Array
(
[name] => /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
[subject] => Array
(
[C] => US
[ST] => California
[L] => Mountain View
[O] => Google Inc
[CN] => mx.google.com
)
[hash] => fbf7dda6
[issuer] => Array
(
[C] => US
[O] => Google Inc
[CN] => Google Internet Authority
)
[version] => 2
[serialNumber] => 280762463620984597407910
[validFrom] => 120912115656Z
[validTo] => 130607194327Z
[validFrom_time_t] => 1347451016
[validTo_time_t] => 1370634207
[purposes] => Array
(
[1] => Array
(
[0] => 1
[1] =>
[2] => sslclient
)
[2] => Array
(
[0] => 1
[1] =>
[2] => sslserver
)
[3] => Array
(
[0] => 1
[1] =>
[2] => nssslserver
)
[4] => Array
(
[0] =>
[1] =>
[2] => smimesign
)
[5] => Array
(
[0] =>
[1] =>
[2] => smimeencrypt
)
[6] => Array
(
[0] => 1
[1] =>
[2] => crlsign
)
[7] => Array
(
[0] => 1
[1] => 1
[2] => any
)
[8] => Array
(
[0] => 1
[1] =>
[2] => ocsphelper
)
)
[extensions] => Array
(
[extendedKeyUsage] => TLS Web Server Authentication, TLS Web Client Authentication
[subjectKeyIdentifier] => 69:B3:67:5C:04:7F:16:EF:C1:85:FB:E8:2D:E4:FC:21:E9:7D:93:AF
[authorityKeyIdentifier] => keyid:BF:C0:30:EB:F5:43:11:3E:67:BA:9E:91:FB:FC:6A:DA:E3:6B:12:24
[crlDistributionPoints] => URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl
[authorityInfoAccess] => CA Issuers - URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crt
[basicConstraints] => CA:FALSE
[subjectAltName] => DNS:mx.google.com
)
)

Answer 1

There are two possible reasons for this.
Firstly SMTP host name matching has traditionally been defined quite vaguely. You can check the historical notes about this in RFC 6125 (a recent RFC about best practicises for host name verification, not yet widely implemented). RFC 3207 (Secure SMTP over Transport Layer Security) doesn't give much details as to where the host name should be in the certificate. RFC 4954 (SMTP Service Extension for Authentication) gives more details and talks about Subject Alternative Names, but it's in the context of SASL. Ambiguous or vague host name matching specifications are often a reason why no correct attempt to match the host name is made at all, unfortunately.
Secondly, SSL/TLS is rarely used between Mail Transfer Agents (MTA). What you're doing by getting the MX DNS record and trying to send an e-mail directly to it is typically done my MTAs, not so much by a Mail Submission Agent.
Typical usage of SSL/TLS for SMTP is between a Mail User Agent (the e-mail client) and a Mail Submission Agent (your ISP's e-mail server, where you have to authenticate).
SSL/TLS between MTAs is hard to set up, because not every server supports it and it's hard to know which MTAs will support it. Some people advocate "optimistic TLS" support, whereby you try to see whether the server you're talking to supports TLS and fall back to plain SMTP if it doesn't. There's unfortunately little to gain by doing so, since you're obviously vulnerable to MITM attacks as soon as you're willing to downgrade anyway.
In addition, the MX entry you get may itself have been compromised (at least without DNSSEC).
Overall, this actually makes it quite hard to rely on any form of transport security for e-mail beyond the MUA/MSA connection. This probably explains why there's little emphasis on configuring MX servers properly for SSL/TLS.