4

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

その後、SSLへの切り替え要求を開始したgmail-smtp-in.l.google.com後、正常に接続しました。ただし、証明書にリストされているホストが接続していたドメインとも一致することを確認するようにスクリプトを設定しました。EHLOSTARTTLS

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
        )

)
4

1 に答える 1

5

これには2つの理由が考えられます。

  • まず、SMTPホスト名の一致は、従来、かなり漠然と定義されてきました。これに関する履歴ノートは、RFC 6125（ホスト名検証のベストプラクティスに関する最近のRFCであり、まだ広く実装されていません）で確認できます。RFC 3207（Secure SMTP over Transport Layer Security）には、ホスト名を証明書のどこに配置するかについての詳細は記載されていません。RFC 4954（認証用のSMTPサービス拡張）は、サブジェクト代替名についての詳細と説明を提供しますが、これはSASLのコンテキストにあります。あいまいまたはあいまいなホスト名の一致仕様は、残念ながら、ホスト名を一致させる正しい試みがまったく行われない理由であることがよくあります。

  • 次に、SSL / TLSがメール転送エージェント（MTA）間で使用されることはめったにありません。MX DNSレコードを取得し、それに直接電子メールを送信しようとすることによって行うことは、通常、私のMTAで行われ、メール送信エージェントではあまり行われません。

    SMTPのSSL/TLSの一般的な使用法は、メールユーザーエージェント（電子メールクライアント）とメール送信エージェント（認証が必要なISPの電子メールサーバー）の間です。

    すべてのサーバーがSSL/TLSをサポートしているわけではなく、どのMTAがSSL / TLSをサポートするかを知るのが難しいため、MTA間のSSL/TLSを設定するのは困難です。一部の人々は「楽観的TLS」サポートを提唱しています。これにより、話しているサーバーがTLSをサポートしているかどうかを確認し、サポートしていない場合はプレーンSMTPにフォールバックします。とにかくダウングレードする意思があるとすぐにMITM攻撃に対して明らかに脆弱になるため、残念ながらそうすることで得られるものはほとんどありません。

    さらに、取得したMXエントリ自体が侵害されている可能性があります（少なくともDNSSECがない場合）。

    全体として、これにより、MUA/MSA接続を超えた電子メールのトランスポートセキュリティに依存することは実際には非常に困難になります。これはおそらく、SSL/TLS用にMXサーバーを適切に構成することにほとんど重点が置かれていない理由を説明しています。

于 2012-11-18T18:58:32.397 に答える