TLSのGoogle false startにセキュリティ上の問題はありますか？
Googleは最近、Chromeブラウザで誤った起動を発表し、TLSパフォーマンスを30％向上させました http://news.softpedia.com/news/Google-Chrome-s-SSL-False- Start-201253.shtml
私はTLSが長年に渡って多くの人々によって突き刺され、研究されてきたことを知っていますが、それでも実装が間違っている可能性があります。 Googleがこのパフォーマンスの向上を達成する方法について、セキュリティの弱点や潜在的な脆弱性に関する調査を知っている人はいますか（たとえ悪用コードがまだ作成されていなくても）。特にセキュリティと暗号化に関して、私は無料の昼食を疑っています。
「TLS false start」の要点は、通常のTLSハンドシェイクの最後に、各パーティがFinishedメッセージをピアに送信し、そのピアからFinishedまで待機する必要があるということです。アプリケーションデータを送信します。 「False start」は、「待つべき」を取り除きます。その後、各当事者はすぐにアプリケーションデータを送信できます。これは、Finishedを最初に送信する当事者がalsoアプリケーションデータを最初に送信する当事者である場合、レイテンシが低いことを意味します。
TLSハンドシェイクには、「フル」ハンドシェイクと「省略」ハンドシェイクの2種類があることに注意してください。後者は、TLSセッションを「再開」するために使用されます。つまり、すでに交換されたマスターキーに対して新しいセッションキーを再計算します。短縮ハンドシェイクは対称暗号化のみを使用し、必要なネットワーク交換が少なくなります。注目に値する点は、フルハンドシェイクではクライアントが最初にFinishedメッセージを送信するのに対し、省略ハンドシェイクではサーバーが最初にFinishedメッセージを送信することです。
HTTPSおよびWebサイトのコンテキストでは、クライアント（Webブラウザ）は通常、単一の完全なTLSハンドシェイクを開始します。次に、クライアントは他のいくつかの並列接続を開くこともできます。今回は省略されたハンドシェイクを使用します。各接続は、いくつかのHTTP要求を送信するために使用されます。接続がタイムアウトになった場合、ブラウザは省略されたハンドシェイクを使用して新しい接続を開きます。 HTTPSはTLS内のHTTPであり、HTTPはリクエストによって開始されるクライアントからなので、「false start」最適化は、サーバーへの最初のTLS接続内の最初のHTTPリクエストに対してのみ改善をもたらします。これは実際には無料のランチではなく、せいぜい無料の前菜です。
暗号学的に言えば、false startで発生するのは、クライアントが実際のサーバーと実際に通信したことを確認する前に、データ（HTTP要求）の送信を受け入れることです。その時点で、クライアントの観点から、サーバーは- 暗黙的に認証された。アプリケーションデータは、認証されたサーバーの公開キー（サーバー証明書のキー）を使用したキー交換から派生したセッションキーで暗号化されているため、なりすましの攻撃者が少なくともその方法で情報を入手できるという実際のリスクはありません鍵交換アルゴリズムと対称暗号化アルゴリズムは安全です。ただし、クライアントは、要求を送信するときに、目的のサーバーが接続の試行を実際に認識しているという証拠はありません。これは無害ですHTTPSのコンテキストでは。そこに害はないと仮定するのは大胆でしょう一般的に。