便宜的 TLS

Opportunistic TLS (Transport Layer Security) は、プレーン テキスト通信プロトコルの拡張機能を指し、暗号化された通信に別のポートを使用する代わりに、プレーン テキスト接続を暗号化された ( TLSまたはSSL ) 接続にアップグレードする方法を提供します。いくつかのプロトコルでは、この目的で「 STARTTLS 」というコマンドを使用します。これは、日和見暗号化の一種であり、主に受動的な監視への対策として意図されています。

IMAPとPOP3のSTARTTLSコマンドはRFC 2595で定義され 、SMTPはRFC  3207で、 XMPPはRFC  6120で、 NNTPはRFC  4642で定義されています。IRCについては、IRCv3ワーキンググループがSTARTTLS拡張を定義しましたが、後に廃止されました。^[1] FTPはRFC  4217で定義されているコマンド「AUTH TLS」を使用し、 LDAPはRFC  2830でプロトコル拡張OIDを定義します。HTTPはアップグレードヘッダーを使用します。

TLSはアプリケーションに依存しません。RFC  5246 では次のように述べられています。

TLS の利点の 1 つは、アプリケーション プロトコルに依存しないことです。高レベルのプロトコルは、TLS プロトコルの上に透過的に重ねることができます。ただし、TLS 標準では、プロトコルが TLS でセキュリティを追加する方法は指定されていません。TLS ハンドシェイクを開始する方法と、交換される認証証明書を解釈する方法の決定は、TLS 上で実行されるプロトコルの設計者と実装者の判断に委ねられています。^[2]

TLSの使用方法を指定するために使用されるスタイルは、TLSのいくつかのライブラリ実装によって便利にサポートされている同じレイヤーの区別と一致します。たとえば、RFC  3207 SMTP拡張は、クライアントとサーバーが安全なセッションを開始する方法を次のダイアログで示しています。^[3]

  S: <TCP ポート 25 で接続を待機します>
  C: <接続を開く>
  S: 220 mail.example.org ESMTPサービス準備完了
  C: EHLO クライアント.example.org
  S: 250-mail.example.orgは温かい歓迎の抱擁を提供します
  S: 250 スタートル
  C: スタートルス
  S: 220 どうぞ
  C: <TLSネゴシエーションを開始>
  C & S: <TLSセッションをネゴシエート>
  C & S: <交渉結果を確認>
  C: EHLO client.example.org [4]
  . . .

上記の最後のEHLOコマンドは、安全なチャネルを介して発行されます。SMTP では認証はオプションであり、省略されたサーバー応答は、プレーンテキスト応答には存在しない AUTH PLAIN SMTP 拡張を安全にアドバタイズできることに注意してください。

便宜的 TLS の使用に加えて、よく知られているプロトコルの SSL で保護されたバージョン用に多数の TCP ポートが定義されました。これらは安全な通信を確立し、古い暗号化されていないプロトコルと同一の通信ストリームを提供します。個別の SSL ポートには、ラウンドトリップが少なくなるという利点があります。また、暗号化されていない形式で送信されるメタデータも少なくなります。^[5]例としては、次のものがあります。

少なくとも電子メール関連のプロトコルに関しては、RFC  8314 では STARTTLS ではなく個別の SSL ポートが推奨されています。

Opportunistic TLS は、日和見暗号化メカニズムです。最初のハンドシェイクはプレーン テキストで行われるため、ネットワークを制御する攻撃者は中間者攻撃によってサーバー メッセージを改ざんし、TLS が利用できないように見せかけることができます ( STRIPTLS 攻撃と呼ばれます)。ほとんどの SMTP クライアントは、電子メールとパスワードをプレーン テキストで送信しますが、多くの場合、ユーザーに通知されません。^[要出典]特に、多くの SMTP 接続はメール サーバー間で行われ、ユーザーへの通知は現実的ではありません。

2014年9月、タイの2つのISPが自社の顧客に対して同様の行為を行っていたことが判明した。 ^{[6] [7]} 2014年10月、AT&Tの子会社であるCricket Wirelessが自社の顧客に対して同様の行為を行っていたことが明らかになった。この行為は2013年9月にAio Wirelessによって開始され、後にCricketと合併した後もこの慣行は継続された。^{[8] [6]}

STRIPTLS 攻撃は、SMTP クライアントが送信接続に TLS を要求するように設定することでブロックできます (たとえば、Exim メッセージ転送エージェントは、ディレクティブ "hosts_require_tls" ^[9]を介して TLS を要求することができます)。ただし、すべてのメール サーバーが TLS をサポートしているわけではないため、すべての接続に TLS を要求するだけでは現実的ではありません。

タイの大規模監視技術で使用されているタイプのSTRIPTLS攻撃の例: ^[10]

クライアント側がサポートしている場合（クライアントの名前解決とクライアントの上流 DNS サーバー）、この問題はDNSSECの一部であるDNS ベースの名前エンティティ認証(DANE) 、特にSMTP 用のRFC  7672 によって対処できます。DANE では、TLSA レコードを介してセキュア SMTP のサポートを宣伝できます。これにより、接続するクライアントに TLS を要求するように通知し、STRIPTLS 攻撃を防止できます。Electronic Frontier Foundationの STARTTLS Everywhere プロジェクトも同様の方法で動作します。ただし、DNSSEC は、展開の複雑さと独特の^{[説明が必要]}批判のために^[11]採用率が低く、Microsoft、Google、Yahoo などの大手メール サービス プロバイダーのグループによって SMTP MTA Strict Transport Security または MTA-STS と呼ばれる新しいプロトコルが起草されました^[12]。 MTA-STS では、DANE TLSA レコードの認証に DNSSEC を使用する必要はありませんが、傍受を回避するために証明機関(CA) システムと初回使用時の信頼 (TOFU) アプローチに依存しています。TOFU モデルは複雑さを軽減しますが、DNSSEC が提供する初回使用時の保証はありません。さらに、MTA-STS は障害報告のメカニズムとレポートのみのモードを導入し、コンプライアンスの段階的な展開と監査を可能にします。

エドワード・スノーデンによる世界的な大規模監視スキャンダルの暴露を受けて、大手メールプロバイダーはSTARTTLSを有効にしてメールのセキュリティを強化しました。^[13] Facebookは、STARTTLSを有効にし、他のプロバイダーにも同様のことを奨励した後^、2014年2月にFacebookがメールサービスを停止するまで、送信メールの95%がPerfect Forward Secrecyと厳格^な証明書検証の両方で暗号化されたと報告しました。^[14]

• セキュアメールテストとツールは、上記の例のようにリアルタイムダイアログでSTARTTLSを検証します。
• 受信ドメインでメールのSTARTTLSが有効になっているかどうか、またどのセキュリティレベルで有効になっているかを確認します。
• Margolis, Daniel; Risher, Mark; Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet. 「SMTP MTA Strict Transport Security (MTA-STS)」。IETF。メール サービス プロバイダーが、トランスポート層セキュリティ (TLS) の安全な SMTP 接続を受信する能力を宣言できるようにするメカニズム。