Email Encryption

メール暗号化とは、電子メールの通信内容を第三者による盗聴や改ざんから保護するための技術です。メール暗号化には大きく分けて、メールサーバー間の通信経路を暗号化するトランスポート層暗号化（Transport-Level Encryption）と、送信者から受信者まで一貫して暗号化するエンドツーエンド暗号化（End-to-End Encryption）の2つのアプローチがあります。

STARTTLSは、SMTP通信において平文接続をTLS暗号化接続にアップグレードするプロトコル拡張です。メールサーバー間の通信を暗号化し、経路上での盗聴を防止します。しかし、STARTTLSは日和見暗号化（Opportunistic Encryption）であり、相手サーバーがTLSに対応していない場合や、中間者攻撃によってTLSネゴシエーションが妨害された場合は、平文にフォールバックしてしまうという根本的な弱点があります。

この弱点を補強するために、MTA-STS（Mail Transfer Agent Strict Transport Security）とDANE（DNS-Based Authentication of Named Entities）が策定されました。MTA-STSはHTTPSを利用してTLS暗号化のポリシーを公開し、受信側メールサーバーがTLS暗号化を強制する意思を宣言します。DANEはDNSSECで保護されたTLSAレコードにより、メールサーバーのTLS証明書を検証します。これらの技術により、STARTTLSのダウングレード攻撃を防ぎ、強制暗号化（Enforced Encryption）を実現できます。

STARTTLSの仕組みと限界

STARTTLSは、SMTP（ポート25/587）接続において、クライアントが「STARTTLS」コマンドを発行し、サーバーが応答した後にTLSハンドシェイクを開始する仕組みです。これにより、既存のSMTPインフラを変更することなく暗号化を導入できます。

しかし、STARTTLSには重大な弱点があります。TLSネゴシエーションが開始される前の通信は平文であるため、中間者攻撃者がSTARTTLSコマンドやサーバーのSTARTTLS対応通知を除去するストリップ攻撃（STARTTLS Stripping）が可能です。この場合、メールは平文のまま送信されますが、送信側のメールサーバーはエラーを返さないため、送信者が暗号化の失敗に気づくことは困難です。

MTA-STS（Mail Transfer Agent Strict Transport Security）

MTA-STS（RFC 8461）は、受信側ドメインがTLS暗号化を強制するポリシーを公開するための仕組みです。送信側メールサーバーは、受信側ドメインの_mta-sts.example.comのDNS TXTレコードを確認し、https://mta-sts.example.com/.well-known/mta-sts.txtからポリシーファイルを取得します。

ポリシーモードには「enforce（強制）」「testing（テスト）」「none（無効）」があります。enforceモードでは、TLS接続の確立に失敗した場合、送信側サーバーはメールを配送せずにバウンスします。これにより、STARTTLSのストリップ攻撃やダウングレード攻撃を効果的に防止できます。ただし、MTA-STSはHTTPS経由でポリシーを取得するため、TOFU（Trust on First Use）の問題が残ります。

DANE / TLSA（DNS-Based Authentication of Named Entities）

DANE（RFC 7672）は、DNSSECで保護されたDNSレコード（TLSAレコード）を使用して、メールサーバーのTLS証明書を検証する仕組みです。送信側メールサーバーは、受信側メールサーバーのTLSAレコードを参照し、提示されたTLS証明書がDNSで公開された情報と一致するかを検証します。

DANEはDNSSECに基づいているため、MTA-STSのようなTOFUの問題がなく、初回接続時からダウングレード攻撃を防止できます。一方で、DNSSECの導入が前提条件であり、世界的にDNSSECの普及率はまだ十分とは言えないのが現状です。そのため、MTA-STSとDANEは補完的に使用されることが多くなっています。

TLS Reporting（SMTP TLS Reporting）

TLS Reporting（RFC 8460）は、メール送信時のTLSネゴシエーションの成功・失敗を送信側サーバーが受信側ドメインに報告する仕組みです。受信側ドメインは、_smtp._tls.example.comのDNS TXTレコードで報告先のメールアドレスやHTTPSエンドポイントを指定します。

TLS Reportingにより、MTA-STSやDANEのポリシー適用状況を監視でき、設定の問題やダウングレード攻撃の試行を検知できます。JSON形式のレポートには、成功・失敗の件数、失敗理由（証明書不一致、ポリシー違反など）が含まれます。DMARCレポートと同様に、メール暗号化の運用監視に不可欠なツールです。

日和見暗号化と強制暗号化

日和見暗号化（Opportunistic Encryption）は、相手が暗号化に対応していれば暗号化を行い、対応していなければ平文で通信を続けるアプローチです。STARTTLSの標準動作がこれに該当します。導入の障壁は低いですが、中間者攻撃に対して脆弱です。

強制暗号化（Enforced Encryption）は、暗号化が確立できない場合にはメール配送を拒否するアプローチです。MTA-STSのenforceモードやDANEがこれを実現します。セキュリティは向上しますが、設定ミスによるメール配送障害のリスクがあるため、導入時には十分なテストとTLS Reportingによる監視が必要です。

トランスポート層暗号化とエンドツーエンド暗号化

トランスポート層暗号化（STARTTLS / MTA-STS / DANE）は、メールサーバー間の通信経路を暗号化しますが、メールサーバー上ではメールは復号された状態で保存・処理されます。そのため、メールサーバーの管理者や、サーバーに不正アクセスした攻撃者はメール内容を閲覧可能です。

これに対してエンドツーエンド暗号化（PGP/GPG、S/MIME）は、送信者のデバイスで暗号化し、受信者のデバイスでのみ復号するため、経路上のサーバーではメール内容が保護されます。両方のアプローチを組み合わせることで、通信経路とメール内容の両方を保護する多層防御を実現できます。

• 01
  STARTTLSの確実な有効化と最新TLSバージョンの使用：すべてのメールサーバーでSTARTTLSを有効化し、TLS 1.2以上（推奨はTLS 1.3）を使用してください。SSL 3.0やTLS 1.0/1.1は脆弱性があるため無効化し、安全な暗号スイートのみを許可する設定を行いましょう。
• 02
  MTA-STSポリシーの導入と段階的な強制化：まずtestingモードでMTA-STSポリシーを公開し、TLS Reportingでメール配送状況を監視してください。十分な検証期間を経た後、enforceモードに切り替えることで、STARTTLSのダウングレード攻撃を防止できます。
• 03
  DANE/TLSAレコードの設定：DNSSECが導入済みのドメインでは、TLSAレコードを公開してDANEによる証明書検証を有効化してください。TLSAレコードはメールサーバーのTLS証明書更新時に同期して更新する運用手順を確立しましょう。
• 04
  TLS Reportingの設定と定期的な監視：_smtp._tls DNSレコードを設定し、TLS Reportingを有効化してください。受信したレポートを定期的に分析し、TLSネゴシエーションの失敗率やポリシー違反を監視することで、設定の問題やダウングレード攻撃の試行を早期に検知できます。
• 05
  証明書の適切な管理と自動更新：メールサーバーのTLS証明書はLet's Encryptなどの認証局から取得し、自動更新を設定してください。証明書の有効期限切れはメール配送障害の原因となるため、期限切れ前の通知アラートも設定しましょう。
• 06
  エンドツーエンド暗号化との併用：トランスポート層暗号化だけでは中間サーバー上のメール内容は保護されません。機密性の高い通信には、PGP/GPGやS/MIMEによるエンドツーエンド暗号化を併用し、多層防御の体制を構築してください。