CloudflareのNickSullivanからのツイートに示されているように、Apple、Cloudflare、Fastly、MozillaがIETF102ハッカソンでHTTPSのサーバー名識別メカニズムの暗号化を強化するために協力しているというニュースが出ました。ツイートは、「素晴らしい仕事」と言って、そこで働くサーバーへのリンクの下で共有することによって、4人の技術巨人からのミックスチームを祝福しました esni.examp1e.net そして cloudflare-esni.com 。
暗号化されたSNIチームによるIETF102ハッカソンでの素晴らしい仕事 @Cloudflare @fastly @mozilla そして @林檎 。現在、BoringSSL、NSS、およびpicotlsに実装があります。
稼働中のサーバーは https://t.co/sLI9xLRjlK そして https://t.co/AoC2SIlJ7N 。
— Nick Sullivan（@grittygrease） 2018年7月15日
IETF Hackathonは、若い開発者や技術愛好家を招待して、今日の一般ユーザーが直面している技術関連の問題の解決策の草案作成に参加するプラットフォームです。イベントは無料で参加でき、誰でも参加でき、競争ではなくチームワークを促進します。今年のIETFハッカソンは14日にモントリオールで開催されましたthおよび15th7月の。それから得られる最も顕著な成果は、トランスポート層セキュリティ（TLS）サーバー名表示（SNI）の暗号化であるようです。これは、過去10年間、開発者を悩ませてきた問題であり、Apple、Cloudflare、Fastlyのメンバーです。 、およびMozillaは、の解決策を提案しました。
IETFハッカソンイベント。 IETF
過去10年半の間に、ハイパーテキスト転送プロトコル（HTTP）からトランスポート層セキュリティサーバー名表示ハイパーテキスト転送プロトコルセキュア（TLS SNI HTTPS）への明確なグローバルシフトがありました。ザ・ 問題 TLS SNI HTTPSシステムの最適化から生まれたのは、後で復号化するためにデータ転送を照合するという目的に反してSNIを使用するハッカーの能力でした。
SNIが開発される前は、同じ最初のクライアントハンドシェイクを使用して複数の仮想サーバーへの安全な接続を確立することは困難でした。 1つのIPアドレスが1つのサーバーと対話すると、2つは「hello」を交換し、サーバーは証明書を送信し、コンピューターはクライアントキーを送信し、2つは「ChangeCipherSpec」コマンドを交換し、接続が確立されると対話が終了しました。これは、今言ったように簡単に聞こえるかもしれませんが、プロセスには複数の交換と応答が含まれ、通信するサーバーの数が増えるにつれて、非常に問題が発生しやすくなりました。すべてのサイトが同じ証明書を使用している場合、これはそれほど問題ではありませんでしたが、残念ながら、そうなることはめったにありませんでした。複数のサイトがさまざまな証明書をやり取りしていると、サーバーがコンピューターが探している証明書を特定することが困難になり、複雑な交換Webで、誰がいつ何を送信したかを特定することが困難になり、アクティビティ全体が終了しました。完全に警告メッセージが表示されます。
その後、TLS SNIは2003年6月にIETFサミットを通じて導入されました。その目的は、ある意味で、ExchangeWebに関連するコンピューターとサービスの名前タグを作成することでした。これにより、サーバーが必要な正確な証明書を提供できるようになり、2人が誰が何を言ったかについて混乱することなく独自の会話交換ができるようになったため、サーバーとクライアントのhello交換プロセスがはるかに簡単になりました。これは、チャットの連絡先名を持っていて、メッセージの送信元について混乱しないようにし、各クエリに適切に応答して、必要なコンピュータに適切なドキュメントを提供できるのと少し似ています。このSNI定義は、交換プロセスを最適化するこの方法で最大の問題を引き起こしたものです。
HTTPSへの切り替えで多くの企業が直面した苦労は、各証明書の要求を実行するために、個々のIPアドレスを使用して多くの証明書をSNI形式に適合させることでした。 TLSが彼らのためにしたことは、そのような要求に応答するための証明書の生成をより簡単にすることであり、SNIがさらに行ったことは、インターネットのネットワーク全体に識別システム全体を投入することによって、個別の専用証明書IPアドレスの必要性を排除することでした。今世紀のアップグレードに伴ってもたらされたのは、ハッカーが確立された「連絡先名」を使用してデータ転送を監視およびシャドウイングし、後の段階で復号化する必要のある情報を抽出できるようになったという事実です。
TLSは暗号化されたチャネルでデータを送受信することを許可し、SNIはデータが正しい宛先に到達することを保証しますが、後者はハッカーがDNS要求、IPアドレスに従ってオンラインアクティビティを監視し、ソースと照合する手段も提供しました、およびデータストリーム。 DNS情報をTLSチャネルを介して渡すことにより、より厳格なSNIコーディングポリシーが実装されていますが、ハッカーがこれを識別手段として使用して、抽出および分離したい情報を追跡できるようにするための小さなウィンドウが残っています。復号化。 TLS暗号化データのより多くのトラフィックを処理する複雑なサーバーは、プレーンテキストのSNIを使用してサーバー内で通信を送信します。これにより、ハッカーは追跡したい情報のチャネルとストリームを簡単に識別できます。ハッカーが目的のデータのSNI情報を抽出できるようになると、ハッカーはサーバーとの別のTLS接続でコマンドの偽の再生を設定し、盗まれたSNI情報を送信して、次のような情報を取得できるようになります。それに関連付けられていました。過去にこのSNIの問題を解決するためのいくつかの試みがありましたが、ほとんどはSNIがサーバーの便利な識別方法にするために動作する単純さの原則に反しています。
この方法を確立するために最初に取り組んだサミットに戻ると、4人の技術大手の参加者がモントリオールでの会議に戻ってTLS SNIの暗号化を開発しました。これは、マルチHTTPS隣接システムの効率が高いにもかかわらず、セキュリティが依然として懸念事項であるためです。以前と同じように。
TLSでSNIを隠すには、ハッカーが見る可能性のある「フロントサービス」の表示下に「隠しサービス」を保持する必要があります。隠されたサービスを直接観察することができなければ、ハッカーは、暗号化されたデータを中継するために使用される基礎となるシークレットサービスのパラメータを識別できずに、プレーンテキストで隠れているという正面の変装によって誤った方向に導かれます。オブザーバーがフロントサービスの証跡をたどると、データは監視対象のチャネルから削除され、目的の隠しサービスにリダイレクトされます。その時点で、ハッカーはその証跡を失います。サーバーはフロントサービスにも公開されるため、データがそこに到達すると、2番目の並列SNI信号がフロントサービスに送信され、データが非表示のサービスにリダイレクトされます。この方向変更プロセスでは、ハッカーはサーバーのWebで失われます。この二重チケットのメカニズムは、同じSNIの下で結合チケットにさらに発展します。 1つのデータがサーバーに送信されると、そのデータは協調するSNIリダイレクターを生成し、2つはTLS暗号化データを必要な場所に取得するために連携して機能します。両方のSNIトラックをカバーするランダム化されたフロントサービスを解読できなければ、ハッカーはデータの追跡を追跡できませんが、サーバーは2つを接続し、データの最終的な場所として非表示のサービスを復号化できます。これにより、サーバーは引き続きSNIを使用して、TLS暗号化でのデータ転送を最適化すると同時に、ハッカーがSNIメカニズムを利用できないようにすることができます。
