要約

  • 完全なTLS handshakeで、False Startはクライアント自身のFinished後、サーバーFinishedが戻る途中に、新しい鍵でアプリケーションデータを送れた。
  • 通常の認証は残り、早い解放にはアプリの明示選択、暗号条件のwhitelist、確定したプロトコル、後続失敗の扱いが必要だった。

最初のrecordが最後の証明を追い越した

RFC 5246 の通常順序では、クライアントはサーバー証明書と鍵交換を処理し、ChangeCipherSpecとFinishedを送り、サーバー側の対応する二つを待つ。相手のFinishedを検証して初めてhandshakeが完了し、アプリデータを送る。

False Startはその待ち時間へ最初のrecordを移した。クライアントは新しい鍵を計算済みで、自分の証明も送信済みである。暗号化recordがサーバーへ進む間、サーバーの最終証明が逆向きに戻る。

RFC 7918 は成功を「遡及的に検証」と説明する。サーバーFinishedが正しければ最終的なhandshakeは通常通り有効で、変わったのは時刻だけだ。一往復を消したのではなく、結果が返る前にその時間を使った。

すでに暗号化できたが、まだ完了を知らなかった

送信時点でServerHello、cipher suite、証明書、鍵交換parameterは見えている。recordは新しいCipher Specで守られる。ClientHelloと同時に平文を投げる動作ではない。

未確認なのはサーバーFinishedである。相手が同じ秘密とtranscriptを持つことを最終確認する。届かなければ、または一致しなければhandshakeは成立しない。標準順序ならデータを保持した場面で、False Startはすでに手放している。

問うべきは「暗号化されたか」だけでなく、「最後の認証結果より先に何を開示できるか」だった。

サーバーの許可ではなくクライアントの挙動

False Start専用extensionでサーバーが同意したわけではない。RFC 7918は任意のクライアント動作を定める。互換serverとは、通常のstate machineより早く保護recordが来ても耐えられる実装である。

互換性はapplication profileなど外部知識から得られた。無言を同意にしてはならない。middleboxやserverのresetは順序仮定の不一致であり、鍵の破綻ではない。

application layer自身が機能を要求する。TLS libraryには、最初のmessageが安全な読取りか、credentialか、不可逆な命令か分からない。意味を知る層がlatencyとの交換を決める。

whitelistが近道の範囲を決めた

RFC 7918はprotocol version、symmetric cipher、key exchange、parameter、client certificate typeを限定する。推奨DHE/ECDHEはforward secrecyを提供する。不確かな組合せではFalse Startしない。

downgradeで弱い条件へ移されたときに、すでに出たデータを守るためである。一方、whitelistは運用資産になる。library update、fallback、default変更で対象が勝手に広がれば、applicationが審査していない開示が始まる。

最終成功だけでなく、その時点の正確な条件が早期送信を許可されていたかを証明する必要がある。

話す言語を先に確定した

RFC 7301 のALPNは、ClientHelloで候補を示しServerHelloで一つを選ぶ。False Start判断より前にapplication protocolが確定する。

ALPN自体は早期送信を認可しない。しかしserverがどのgrammarで最初のrecordを読むかを確定する。application opt-in、ALPN結果、暗号whitelistが同じprofileを指さなければならない。

暗号が強くても、異なるprotocolへ渡したbyteは安全にならない。

失敗は将来を止めてもrecordを呼び戻せない

サーバーFinishedが正しければhandshakeは継続する。欠落または不一致ならclientは失敗させ、認証errorとして扱う。単なるtimeoutへ落としたり、副作用ある操作を自動再送したりしてはならない。

切断は後続を止めるが、peerやactive endpointへ届いたrecordを回収しない。経路上のconfidentialityと、その相手へ今開示してよいかは別の判断である。

False Startは0-RTTではない

RFC 8446 のTLS 1.3は短いflowを設計し、別の0-RTTを持つ。resumptionで0-RTTはClientHello直後、以前のPSKから得た鍵で出る。forward secretでなく、connection間のnon-replay保証がない。

False Startはfull handshakeとfresh keyを使い、client Finished後に送る。未解決なのはserver Finishedであり、PSK dataのreplayではない。

RFC 8470 のHTTP Early-Dataと425 Too Earlyは0-RTT replay用で、False Startの機構ではない。RFC 9325 も0-RTTにapplication固有仕様を要求する。共有されるのはapplication理解の必要性で、security propertyではない。

出典と限界

根拠は RFC 5246、RFC 7301、RFC 7918、RFC 8446、RFC 8470、RFC 9325 である。現行普及率は示さない。False Startは平文送信、証明書省略、session resumption、専用server extensionではない。