为什么 Google 的 MX 服务器与 SSL 证书 CN 不匹配？

Question

在向 google 帐户发送电子邮件之前，我的脚本会查找 google 电子邮件服务器的 MX 记录。结果是：

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

然后我成功连接到gmail-smtp-in.l.google.com，在EHLO 之后我发起了STARTTLS 请求切换到SSL。但是，我将脚本设置为检查并确保证书match the domain 中列出的主机我也在连接。

stream_context_set_option($fh, 'ssl', 'CN_match', 'gmail-smtp-in.l.google.com`);

但是，这就是问题所在。我收到以下错误：

stream_socket_enable_crypto(): Peer certificate CN='mx.google.com' did not match expected CN='gmail-smtp-in.l.google.com'

我查了一下nslookup mx.google.com的位置，发现它不存在。

Server:     127.0.0.1
Address:    127.0.0.1#53

** server can't find mx.google.com: NXDOMAIN

为什么 SSL 证书与使用它的域不匹配？我错过了什么吗？

以下是我的脚本从他们那里收到的证书。

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

这有两个可能的原因。

• 首先，传统上 SMTP 主机名匹配的定义非常模糊。您可以在RFC 6125（最近关于主机名验证最佳实践的 RFC，尚未广泛实施）中查看有关此的历史记录。 RFC 3207（基于传输层安全的安全 SMTP）没有提供关于主机名在证书中的位置的详细信息。 RFC 4954（用于身份验证的 SMTP 服务扩展）提供了更多详细信息并讨论了主题备用名称，但它是在 SASL 的上下文中。不明确或含糊的主机名匹配规范通常是无法正确尝试匹配主机名的一个原因，不幸的是。

• 其次，Mail Transfer Agents (MTA) 之间很少使用 SSL/TLS。通过获取 MX DNS 记录并尝试直接向其发送电子邮件，您所做的通常是我的 MTA，而不是 Mail Submission Agent。

  用于 SMTP 的 SSL/TLS 的典型用法是在邮件用户代理（电子邮件客户端）和邮件提交代理（您的 ISP 的电子邮件服务器，您必须在其中进行身份验证）之间。

  MTA 之间的 SSL/TLS 很难设置，因为不是每个服务器都支持它，而且很难知道哪些 MTA 会支持它。有些人提倡“乐观 TLS”支持，即您尝试查看您正在与之交谈的服务器是否支持 TLS，如果不支持则回退到普通 SMTP。不幸的是，这样做并没有什么好处，因为一旦您愿意降级，您显然很容易受到 MITM 攻击。

  此外，您获得的 MX 条目本身可能已被泄露（至少没有 DNSSEC）。

  总体而言，这实际上使得除了 MUA/MSA 连接之外，很难依赖任何形式的电子邮件传输安全性。这可能解释了为什么很少强调为 SSL/TLS 正确配置 MX 服务器。