4

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
        )

)
Xeoncross
  • 55,620
  • 80
  • 262
  • 364

1 Answers1

5

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.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • So, basically encrypted email doesn't happen because no one cares. Well, at least I know now. – Xeoncross Nov 19 '12 at 00:04
  • I don't think it's because no one cares. Rather, it's because it's very hard to implement. The e-mail distribution system is de-centralised by nature. Using TLS between each relay would require each client relay to trust every possible server. Choosing which CAs one relay should trust or not would require a global agreement, which may end up making the overall system more centralised. – Bruno Nov 19 '12 at 09:53
  • Makes sense, I guess I take the consistency browser CA cert bundles offer for granted. I guess the current best way around this problem is end-to-end encryption with OpenPGP at the user-client level. I've found many TLS MX servers have the same "mx.example.com" CN that Google has. – Xeoncross Nov 19 '12 at 17:29
  • Indeed, I think there's little motivation to use transport level security between mail relays, simply because any of the relays (which are a priori unknown) would be able to read the e-mails (TLS only secures the connections from one node to another). When e-mail integrity and confidentiality is required, message level security like S/MIME and PGP is indeed better. – Bruno Nov 19 '12 at 18:04
  • SMTP STARTTLS is becoming more common every day, initiatives like DNSSEC, DANE and SMTP REQUIRETLS are improving its security. – Jasen Mar 09 '18 at 01:39
  • @Jasen That's certainly true for MUA/MSAs, but I have no figures about MTAs, so I couldn't comment on a trend. It would be interesting if you had any experience/figures regarding MTAs. – Bruno Mar 09 '18 at 09:43