← RFC Reference

TLSとメールセキュリティ

TLSがメール転送をどのように保護するか — STARTTLS、インプリシットTLS、MTA-STS、DANE、TLSRPT — および日和見暗号化が十分でない理由。

問題：SMTPは暗号化なしで設計された

SMTPは1982年（RFC 821）にプレーンテキストプロトコルとして設計された。すべてのコマンド、すべてのレスポンス、すべてのヘッダー、メッセージコンテンツのすべてのバイトがネットワーク上で暗号化されずに送信された。AUTHで送信されたパスワードは事実上、部屋全体に向かって叫ばれていた。

TLS（トランスポートレイヤーセキュリティ）をSMTPに層状に配置してこれを修正した。しかし、HTTPS — TLSが必須かつ普遍的である — とは異なり、メールTLSは今日でもまだ解決されている一連の不完全な妥協を通じて進化してきた。

STARTTLS：日和見暗号化

STARTTLS（RFC 3207）は既存のプレーンテキストSMTP接続をTLSにアップグレードする。プロセス：

STARTTLSについての要点：

• 接続はプレーンテキストで開始され、ミッドストリームでアップグレードされる。最初のEHLOおよびSTARTTLSコマンド自体は暗号化されていない。
• STARTTLSが完了した後、クライアントはEHLOを再度送信する必要がある。サーバーは暗号化された接続を通じて異なる機能をアドバタイズする場合がある。
• STARTTLSはポート25（サーバー間）およびポート587（クライアント送信）で使用される。
• ポート25でのSTARTTLSはデフォルトで日和見的である：サーバーがSTARTTLSをアドバタイズしない場合、またはTLSハンドシェイクが失敗した場合、ほとんどの送信MTAはプレーンテキストにフォールバックしてメッセージを送信する。

STARTTLSストリッピング攻撃

STARTTLSはプレーンテキストで開始されるため、中間者攻撃者はサーバーのEHLOレスポンスを変更してSTARTTLSアドバタイズメントを削除できる。送信MTAはサーバーがTLSをサポートしていないと考え、プレーンテキストで続行する。その後、攻撃者はメッセージを読み取り、変更することができる。

これは理論的な攻撃ではない。特に大量監視を実施している国で、野生で観察されている。日和見的STARTTLSは能動的な攻撃者に対する保護を提供しない — 受動的な盗聴からの保護のみを提供する。

インプリシットTLS：最初のバイトからの暗号化

RFC 8314はメール送信（クライアント間）に対してインプリシットTLSを推奨している。プレーンテキストで開始してアップグレードする代わりに、接続は最初のバイトからTLSである。

• ポート465：メッセージ送信用のインプリシットTLS。クライアントは直ちにTLS接続を開く。STARTTLSステップなし。ストリッピング機会なし。
• ポート993：IMAP用インプリシットTLS。
• ポート995：POP3用インプリシットTLS。

RFC 8314は、TLSなしでポート587でのプレーンテキストSMTP送信が廃止されたこと、およびポート465でのインプリシットTLSが優先送信パスであることを明確に宣言する。実際には、ポート587とSTARTTLSは引き続き広く導入されているが、方向は明確である：インプリシットTLSが将来である。

しかし、インプリシットTLSは送信パス（クライアントからサーバー）にのみ適用される。ポート25でのサーバー間配信は、受信者のMXがインプリシットTLSをサポートしていることをサーバーが事前に知るための普遍的に導入されたメカニズムがないため、引き続きSTARTTLSを使用する。これがMTA-STSとDANEの出番である。

MTA-STS：ポリシーベースのTLS強制

MTA-STS（RFC 8461）はSTARTTLSストリッピング問題を解決し、ドメインが「メール配信時に常にMXサーバーへのTLSを必要とする」ポリシーを発行できるようにする。ポリシーはHTTPS（DNS以外）を通じて発行され、Web PKIを通じて独自の認証を提供する。

MTA-STSの仕組み

1. ドメインはMTA-STSポリシーが存在することを示すDNS TXTレコードを発行：

2. 送信MTAはウェルノーンURLからHTTPS経由でポリシーを取得：

3. ポリシーファイルはモードと有効なMXホスト名を指定：

4. 送信MTAはポリシーをキャッシュ（max_age秒間）し、すべての将来の接続で強制する。次の操作を実行：
   • ポート25でSTARTTLSを必須（プレーンテキストへのフォールバックなし）
   • MXホスト名に対するサーバーのTLS証明書を検証
   • ポリシーにリストされたMXホスト名へのみ配信

MTA-STSモード：

• enforce：TLSと有効な証明書を必須とする。TLSを確立できない場合は配信失敗。
• testing：TLSを試みるが、失敗してもとにかく配信。TLSRPTを通じて失敗レポートを送信。
• none：ポリシーなし。以前のポリシーを明示的に取り消すために使用。

MTA-STSはWebと同じ信頼モデルを持つ：認証局に依存する。CAが侵害された場合、攻撃者はMXの証明書を偽造する可能性がある。DANEはDNSSECに基づく代替信頼モデルを提供する。

DANE：DNSベースの証明書検証

DANE（RFC 7672）はDNSSECで署名されたTLSAレコードを使用してTLS証明書（またはその公開鍵）をMXホスト名に直接関連付ける。これは認証局への依存を削除する。

TLSAレコードフィールド：

• 3（証明書使用法）— ドメイン発行証明書（CA不要）
• 1（セレクタ）— サブジェクト公開鍵に対して照合
• 1（照合型）— 公開鍵のSHA-256ハッシュ
• a]b2c3d4e5f6...— ハッシュ値

メール用DANEの仕組み

1. 送信MTAはMXレコードを解決してmx1.example.comを取得。
2. _25._tcp.mx1.example.comでTLSAレコードをクエリ。
3. DNSSEC検証済みのTLSAレコードが存在する場合、MTAは以下を知る：
   • TLSは必須（プレーンテキストへのフォールバックなし）。
   • サーバーの証明書はTLSAレコードと一致する必要がある。
4. MTAは接続し、STARTTLSを実行し、CA システムの代わりに（または加えて）TLSAレコードに対してサーバーの証明書を検証。

DANEの長所：認証局に依存しない。短所：多くのドメインが導入していないDNSSECが必須。DNSSECなしでは、DANEレコードを信頼できない（DNSを操作できる攻撃者もTLSAレコードを操作できる）。

DANEとMTA-STSの比較

両メカニズムは共存できる。ドメインはMTA-STSポリシーとDANEポリシーの両方を発行できる。DANEをサポートする送信者はそれを使用；サポートしない者はMTA-STSにフォールバック可能。

TLSRPT：TLSレポート

SMTP TLSレポート（RFC 8460）により、ドメインは送信サーバーからのTLS接続失敗に関するレポートを受け取ることができる。これはTLSの同等物のDMARC集約レポートである。

TLSRPTをサポートする送信MTAは日々のJSONレポートを送信し、詳細を記す：

• MXへの総接続試行数
• 成功したTLSネゴシエーション
• 失敗したTLSネゴシエーション（理由：証明書エラー、STARTTLS失敗、MTA-STSポリシー違反）
• プレーンテキストへのフォールバック接続

TLSRPTはMTA-STSデプロイ中に不可欠である。MTA-STSポリシーでmode: testingで開始し、TLSRPTレポートを監視。ゼロ（または許容可能な）失敗を確認したら、mode: enforceに移行。

証明書管理

TLSは証明書を必要とし、証明書管理はメールセキュリティにおける最も一般的な運用失敗ポイントの1つである。

メールサーバーの証明書

• 証明書はMXホスト名と一致する必須。MXレコードがmx1.example.comを指す場合、証明書はmx1.example.comに対して有効である必須。example.comまたはwww.example.comの証明書は機能しない。
• 公開CAから証明書を使用。Let's Encryptはメールサーバーに完全に機能する。自己署名証明書は、チェックを行う送信者（MTA-STSまたはDANEを使用する者を含む）のTLS検証失敗を引き起こす。
• 更新を自動化。証明書有効期限切れはTLS失敗の最も一般的な原因である。ACME（Let's Encrypt）またはCAの自動化を使用して、証明書が有効期限切れ前に更新されることを確認。
• すべてのMXホスト名を含める。複数のMXサーバーがある場合、それぞれそのホスト名に対する有効な証明書が必須。SAN（サブジェクト代替名）証明書は複数のホスト名をカバーできる。

証明書エラーとその影響

このテーブルは日和見的TLSの核心問題を明らかにする：MTA-STSまたはDANEなしでは、ほとんどの証明書エラーは無視される。接続は暗号化されるが、認証されない — 攻撃者のサーバーにメッセージを暗号化しているかもしれない。

メール暗号化の状態

メール暗号化は2つのレベルに存在し、しばしば混同される：

トランスポート暗号化（TLS）

TLSはサーバー間の接続を暗号化。転送中の任意の2つのポイント間でのメッセージの盗聴から保護。メッセージが宛先サーバーに到着すると、プレーンテキストで復号化される（通常）。TLSはトランスポートを保護し、メッセージではない。

トランスポート暗号化はホップバイホップ：メッセージはサーバーと次のサーバー間で暗号化され、その後復号化され、次のホップ用に再暗号化。各中間サーバーはプレーンテキストメッセージへのアクセス権を持つ。

エンドツーエンド暗号化（S/MIME、PGP）

エンドツーエンド暗号化（RFC 8551あたりのS/MIME、またはPGP/OpenPGP）はメッセージコンテンツ自体を暗号化し、正しい秘密鍵を持つ意図された受信者のみがそれを復号化できる。メッセージはサーバーで保存中、およびすべてのトランジットホップ中に暗号化されたままである。

メール内のエンドツーエンド暗号化の導入は非常に低いままである。理由は実用的：

• 鍵管理は困難。送信者と受信者の両方が暗号化鍵を管理する必須。ユニバーサル鍵ディレクトリは存在しない。
• ユーザビリティが悪い。ほとんどのメールクライアントは暗号化を煩雑にする。平均的なユーザーはPGP鍵を管理することはできない（そして管理する必要がない）。
• サーバー側機能が破損。サーバーがメッセージを読めない場合、それをインデックスできない、検索できない、スパムをフィルタできない、ルールを適用できない。
• 相互運用性が限定。S/MIMEとPGPは互いに互換性がない。

ほとんどのメールについて、トランスポートレベルのTLSは実用的な暗号化層である。エンドツーエンド暗号化は、運用上の負担が正当化される高セキュリティ環境で使用される限定的なままである。

TLSを要求（RFC 8689）

RFC 8689はメッセージごとのTLS要求メカニズムを定義。送信者は個々のメッセージにREQUIRETLS SMTP拡張を追加：

REQUIRETLSが設定される場合：

• 受信サーバーはメッセージを配信またはリレーするためにTLSを使用する必須。次のホップでTLSが利用できない場合、メッセージはプレーンテキストで送信されるのではなく、返送。
• TLS証明書検証は成功する必須。
• すべてのダウンストリームホップもREQUIRETLSをサポートし、尊重する必須。

REQUIRETLSはメッセージレベル — すべてのメールにTLSを必須にすることなく機密メッセージに使用可能。しかし、導入は依然として限定的。ほとんどのサーバーはまだそれをサポートしていない。

実用的デプロイメントガイド

ドメインのメール用TLSをデプロイするための推奨シーケンス：

ステップ1：MXサーバーでTLSを確保

すべてのMXホスト名に対して公開CAから有効な証明書を取得。更新を自動化。外部送信者からのSTARTTLSが正しく機能することをテスト。

ステップ2：TLSRPTをデプロイ

_smtp._tls TXTレコードを発行してTLS失敗レポートを受け取る。何かを強制する前に監視を開始。

ステップ3：テストモードでMTA-STSをデプロイ

DNS TXTレコードとHTTPSポリシーファイルをmode: testingで発行。TLSRPTレポートを監視して失敗を確認。問題を調査して修正。

ステップ4：MTA-STSをenforceモードに移行

TLSRPTレポートがクリーン結果を示した場合、モードをenforceに変更。DNS TXTレコードでidを増加させてポリシー変更を合図。

ステップ5：DANEを検討（DNSSECを使用する場合）

ドメインがDNSSEC署名されている場合、MXサーバーのTLSAレコードを発行。CAシステムから独立した証明書ピンニングの追加レイヤーを提供。

何が間違う可能性があるか

有効期限切れ証明書は配信失敗を引き起こす

MXサーバーの証明書が有効期限切れ。MTA-STSなし、ほとんどの送信者はエラーを無視してとにかく配信（安全ではないが機能的）。enforce モードのMTA-STS、証明書を検証する送信者は配信を延期。メッセージは送信側でキューイング。送信側の再試行ウィンドウ内（通常4～5日）に修正しない場合、メッセージはバウンス。修正：Let's Encrypt / ACMEでの自動化された証明書更新。

MX変更後のMTA-STSポリシーミスマッチ

新しいMXサーバー（mx3.example.com）を追加するが、MTA-STSポリシーファイルに追加するのを忘れる。キャッシュされたポリシーを持つ送信者は、ポリシーのリストにないため、新しいMXへの接続を拒否。修正：新しいMXレコードを追加する前にMTA-STSポリシーファイルを常に更新し、ポリシーidをDNSで増加させる。

STARTTLSストリッピングが検出されない

MTA-STSもDANEもなし、攻撃者がサーバーのEHLOレスポンスからSTARTTLSを削除。メッセージはプレーンテキストで配信。送信者も受信者も認識なし。修正：MTA-STSをデプロイしてTLSストリッピングを検出可能かつ防止可能にする。

DANE TLSAレコードが古くなる

TLS証明書を回転させるが、DNSのTLSAレコードを更新するのを忘れる。DANEを検証する送信者はミスマッチを確認し、配信を拒否。修正：新しい証明書をデプロイする前にTLSAレコードを常に更新。証明書デプロイメントをDNS更新と調整する自動化を使用。

重要な取り組み

• 日和見的STARTTLSは無いより良いが、能動的な攻撃に対する保護を提供しない。ネットワークトラフィックを変更できる攻撃者は接続からTLSを削除できる。
• MTA-STSはTLSストリッピングを防止し、送信者がキャッシュして強制するポリシーを発行。Web PKI（認証局）に依存。
• DANEはTLSストリッピングを防止し、DNSSEC署名のDNSレコードで証明書データを発行。CAに依存しないが、DNSSECが必須。
• 可能な場合は両方をデプロイ。MTA-STSはより広い送信者サポートを有；DANEはより強いが、DNSSECが必須。一緒に最も多くの地面をカバー。
• TLSRPTは可視性に不可欠。なし、ドメイン内のインバウンドメールがどのくらい頻繁にTLSが失敗するかを知らない。
• 証明書管理は運用上の懸念。更新を自動化。MXホスト名に証明書を一致させる。DANE TLSA更新を使用して証明書回転を調整。
• TLSはトランスポートを保護し、コンテンツを保護しない。エンドツーエンドメッセージ暗号化については、S/MIMEまたはPGPが必須 — ユーザビリティと導入障壁は依然として高い。
• インプリシットTLS（ポート465）は送信の将来。サーバー間配信については、MTA-STS/DANE強制のあるSTARTTLSが現在のベストプラクティス。

さらに読む

Related RFCs