← RFC Reference

RFC 8314: 平文は廃止予定と見なされる

これが存在する理由

メールは歴史的にクライアント・ツー・サーバー通信に3つの平文ポートを使用してきました:

4つすべて平文接続で開始されます。STARTTLSは、これらの接続をストリーム中盤でTLSにアップグレードするために追加されました。しかし、STARTTLSには根本的な弱点があります:

• ダウングレード攻撃。 攻撃者はサーバーレスポンスからSTARTTLS機能を削除でき、多くのクライアントは黙って平文にフォールバックします。
• TLS前コマンドインジェクション。 STARTTLSの完了前の平文フェーズにより、攻撃者がSMTPコマンドをインジェクトし、サーバーはTLSハンドシェイク後にそれを処理します。
• 認証情報の露出。 STARTTLSが失敗するか削除されると、クライアントが平文でAUTH認証情報(ユーザー名とパスワード)を送信する可能性があります。

RFC 8314は、これらの平文接続をメール送信とメールボックスアクセスで廃止予定と宣言し、暗黙的TLSを代わりとして義務付けます。

仕組み

暗黙的TLS対STARTTLS

STARTTLS(古い方法): 平文ポートに接続、平文でグリーティングを交換、STARTTLSコマンドを送信、TLSをネゴシエート、その後暗号化セッションを続行します。

-- ポート587(送信)でのSTARTTLS --
220 mail.example.com ESMTP          ← 平文グリーティング
EHLO client.example.com             ← 平文
250-mail.example.com                ← 平文
250-STARTTLS                        ← 攻撃者がこの行を削除できます
250 OK
STARTTLS                            ← 平文
220 Go ahead                        ← 平文
-- ここでTLSハンドシェイクが発生します --
EHLO client.example.com             ← 現在は暗号化
AUTH PLAIN dXNlcjpwYXNz            ← 暗号化(安全)

暗黙的TLS(RFC 8314の方法): 専用のTLSポートに接続します。TLSハンドシェイクは接続時の最初の処理です。平文フェーズはまったくありません。

-- ポート465(送信)での暗黙的TLS --
-- 接続時にTLSハンドシェイクが即座に発生します --
220 mail.example.com ESMTP          ← 最初のバイトから暗号化
EHLO client.example.com             ← 暗号化
AUTH PLAIN dXNlcjpwYXNz            ← 暗号化

新しいポート割り当て

ポート465は複雑な歴史を持ちます。1990年代後半に「SMTPS」で割り当てられ、その後STARTTLSに有利に無効化されました。RFC 8314は暗黙的TLS送信用にsubmissions(sに注意)として再割り当てします。今回は公式で永続的です。

ポート25について?

ポート25はサーバー間リレー用であり、クライアント送信ではありません。RFC 8314はポート25の動作を変更しません。サーバー間SMTPはオポチュニスティックSTARTTLSを使用し続け、MTA-STSまたはDANEが強制を提供します。この区別は重要です: クライアントは認証情報で認証し(保護する必要がある)、サーバーはDNS、DKIM、SPFを介して認証します。

重要な技術詳細

TLSバージョン要件

RFC 8314はTLS 1.2以降を要求します。TLS 1.0および1.1はRFC 8996で非推奨になります。実際には、TLS 1.2の最小値を要求し、TLS 1.3を推奨する必要があります。

証明書検証

暗黙的TLSでは、クライアントは標準的なWeb PKIルールを使用して、サーバー証明書を予期されたホスト名に対して検証する必要があります。これはSTARTTLSの時代と大きく異なり、多くのクライアントがどの証明書でも受け入れました。証明書は以下を満たす必要があります:

• 信頼されたCertificate Authorityによって発行されます。
• サーバーホスト名(クライアントが接続するホスト名で、必ずしもMXホスト名ではない)と一致します。
• 期限切れまたは失効していません。

サービスディスカバリ用のSRVレコード

RFC 8314は、SRVレコード経由の自動クライアント設定用にRFC 6186と連携します:

クライアント設定

SMTP送信を統合するアプリケーション開発者向け:

# Python例: ポート465での暗黙的TLS
import smtplib

# 正しい: SMTP_SSLは直ちにTLSで接続します
with smtplib.SMTP_SSL('mail.example.com', 465) as smtp:
    smtp.login('user', 'password')
    smtp.send_message(msg)

# 回避: ポート587でのSTARTTLS(レガシー)
# with smtplib.SMTP('mail.example.com', 587) as smtp:
#     smtp.starttls()
#     smtp.login('user', 'password')

よくある間違い

• ポート465とポート25を混同する。 ポート465はクライアント送信用で暗黙的TLSです。ポート25はサーバー間リレー用です。MX配信にはポート465を使用しないでください。
• 依然としてSTARTTLS強制なしでポート587で平文を提供する。 ポート587をサポートする必要がある場合、AUTHの前にSTARTTLSを要求します。平文接続で認証情報を許可しないでください。
• 証明書検証を無効にする。 暗黙的TLSは適切な証明書検証が必要です。verify=Falseまたはそれと同等の設定を行うと、目的が完全に無効になります。代わりに証明書を修正してください。
• TLS 1.0または1.1を使用する。 これらは公式に非推奨です。サーバーを設定してTLS 1.2以降のみを受け入れます。
• ポート465を「SMTPS」(1990年代版)として扱う。 古いSMTPSは無効化されました。ポート465はRFC 8314に従ったsubmissionsです——基盤となる動作は同じ(暗黙的TLS)ですが、適切なIANA登録で公式に標準化されています。
• SRVレコードを公開しない。 _submissions._tcpSRVレコードなしでは、クライアントは暗黙的TLSエンドポイントを自動検出できません。多くはまだポート587のSTARTTLSにデフォルト設定されています。

配信可能性への影響

• 送信者認証情報を保護します。 SMTP送信を使用するアプリケーション(たとえば、アプリがMailer To Goに接続する場合)の場合、ポート465での暗黙的TLSはAPIの認証情報がSTARTTLSアップグレード中でさえ、平文でネットワークを走査しないことを確保します。
• 接続確立が高速です。 暗黙的TLSはSTARTTLSと比較して1ラウンドトリップを保存します(平文EHLOおよびSTARTTLS交換なし)。高容量送信者の場合、これは累積されます。
• 主要プロバイダーに必須です。 Google WorkspaceとMicrosoft 365の両方がポート465での暗黙的TLSをサポートしています。新しい統合の場合、推奨される送信方法です。
• 攻撃のクラスを排除します。 STARTTLSストリップ、コマンドインジェクション、認証情報スニッフィングはすべて暗黙的TLSで不可能です。コンプライアンスに敏感な環境の場合、これは重要です。

Related RFCs