Loading article…
オポチュニスティックTLS（Transport Layer Security）とは、平文通信プロトコルの拡張機能であり、暗号化通信専用のポートを使用する代わりに、平文接続を暗号化（TLSまたはSSL ）接続にアップグレードする方法を提供するものです。いくつかのプロトコルでは、この目的のために「 STARTTLS」または「Explicit TLS 」というコマンドを使用します。これはオポチュニスティック暗号化の一種であり、主に受動的な監視に対する対策として意図されています。
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 の使用方法を指定するために使用されるスタイルは、TLS のいくつかのライブラリ実装で便利にサポートされているレイヤーの区別と一致します。たとえば、RFC 3207 SMTP 拡張機能は、次のダイアログを使用して、クライアントとサーバーが安全なセッションを開始する方法を示しています。[ 3 ]
S: < TCPポート25で接続を待機> C: <接続を開く> S: 220 mail.example.org ESMTPサービス準備完了 C: EHLO client.example.org S: 250-mail.example.org は、温かい歓迎のハグを提供します S: 250 STARTTLS C: STARTTLS 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ではなく、Implicit TLS （別々のSSLポートを使用）を推奨している。
オポチュニスティック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 攻撃を防止します。電子フロンティア財団の 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を有効にし、他のプロバイダーにも同様の対応を促した後、Facebookが2014年2月にメールサービスを終了するまで、送信メールの95%が完全前方秘匿性と厳格な証明書検証の両方で暗号化されていたと報告した。[ 14 ]
hosts_require_tls - Eximは、このリストに一致するホストに配信する際にTLSセッションの使用を要求します。