Zusammenfassung

  • In einem vollständigen TLS-Handshake konnte False Start nach dem Client-Finished neue verschlüsselte Daten senden, während das Server-Finished noch zurückkam.
  • Der normale Handshake blieb Pflicht; frühe Freigabe erforderte Anwendungs-Opt-in, enge kryptografische Listen, festgelegtes Protokoll und Regeln für späteres Scheitern.

Der erste Anwendungsrecord überholte den letzten Beweis

Im Ablauf von RFC 5246 verarbeitet der Client Zertifikat und Schlüsselaustausch, sendet ChangeCipherSpec und Finished und wartet auf die entsprechenden Servernachrichten. Erst nach Prüfung des fremden Finished beginnt gewöhnlich die Anwendung.

False Start legte den ersten Record in dieses Warten. Der Client hatte frische Schlüssel und seinen Beweis gesendet. Der verschlüsselte Record lief zum Server, während dessen Abschlussbeweis zurücklief.

RFC 7918 nennt den Erfolg rückwirkende Validierung. Trifft das Server-Finished korrekt ein, ist der gewöhnliche Handshake gültig; nur das Timing unterscheidet sich. Die Netzrunde verschwand nicht, ihre Zeit wurde vor dem Ergebnis genutzt.

Schutz war vorhanden, die Bestätigung noch nicht

Der Client kennt ServerHello, Suite, Zertifikat und Austauschparameter. Der Record verwendet den neuen Cipher Spec. False Start ist weder Klartext noch eine blinde Sendung neben ClientHello.

Das Server-Finished muss noch bestätigen, dass der Peer dieselben Geheimnisse und dasselbe Transcript besitzt. Fehlt es oder ist es falsch, ist der Handshake nie gültig. Normales Timing hätte Daten zurückgehalten; False Start hat sie freigegeben.

Die operative Frage lautet, welche Informationen vor dem letzten Authentifizierungsergebnis gehen dürfen.

Clientverhalten statt Serverfreigabe

Es gab keine neue False-Start-Extension, mit der der Server zustimmte. RFC 7918 beschreibt optionale Clientlogik. Ein kompatibler Server toleriert geschützte Records vor seinem üblichen Verarbeitungspunkt.

Kompatibilität konnte ein Anwendungsprofil festlegen; Schweigen war keine Zustimmung. Reset oder Stillstand eines Middlebox- oder Serverzustands zeigte eine Reihenfolgeannahme, nicht schwache Schlüssel.

Die Anwendung musste die Option anfordern. Nur sie kannte den Unterschied zwischen einer harmlosen Abfrage, einem Credential und einer irreversiblen Aktion. Die Bibliothek bot die Möglichkeit; die Anwendung verantwortete die Bedeutung.

Whitelists begrenzten die Abkürzung

RFC 7918 begrenzt Version, symmetrische Chiffre, Schlüsselaustausch, Parameter und Client-Zertifikatstyp. Empfohlene DHE/ECDHE-Verfahren bieten Forward Secrecy. Unsichere Kombinationen werden ausgeschlossen.

So darf ein Downgrade keine schon gesendeten Daten unter schwache Bedingungen bringen. Doch die Liste wird zur Lifecycle-Policy: Update, Fallback oder neuer Default kann Berechtigung ausweiten. Das darf nicht unbemerkt von der Anwendung geschehen.

Ein später erfolgreicher TLS-Handshake beweist nicht, dass die genaue Kombination früher senden durfte.

Das Anwendungsprotokoll stand vor der Sendung fest

RFC 7301 verhandelt ALPN in den Hellos: Vorschläge im ClientHello, Auswahl im ServerHello. Der Client kennt damit die Grammatik vor False Start.

ALPN autorisiert die frühe Freigabe nicht, beseitigt aber Protokollraten. Opt-in, Auswahl und kryptografisches Profil müssen dieselbe Anwendung beschreiben. Starke Verschlüsselung macht Bytes für den falschen Parser nicht sicher.

Scheitern holt den Record nicht zurück

Ein korrektes Server-Finished lässt die Sitzung weiterlaufen. Fehlt es oder stimmt es nicht, muss der Client mit Authentifizierungsfehler abbrechen. Er darf das nicht zu Timeout herabstufen oder gefährliche Aktionen automatisch wiederholen.

Der Abbruch verhindert Zukunft, nicht den bereits beim Peer oder aktiven Endpoint angekommenen Record. Pfadvertraulichkeit und Erlaubnis zur jetzigen Offenlegung sind verschiedene Entscheidungen.

False Start war kein 0-RTT

RFC 8446 definiert TLS 1.3 und anderes 0-RTT. Bei Resumption kann Datenverkehr nach ClientHello mit früherem PSK starten; er ist nicht forward secret und nicht verbindungsübergreifend replay-sicher.

False Start nutzt einen vollen Handshake, frische Schlüssel und wartet bis nach Client-Finished. Offen ist das Server-Finished, nicht PSK-Replay.

RFC 8470 gibt HTTP Early-Data und 425 Too Early für 0-RTT. Sie gehören nicht zu False Start. RFC 9325 verlangt Anwendungsspezifikation für 0-RTT und explizite ALPN- und Flottenkontrollen. Die Disziplin ähnelt sich, die Eigenschaft nicht.

Quellen und Grenzen

Quellen sind RFC 5246, RFC 7301, RFC 7918, RFC 8446, RFC 8470 und RFC 9325. Sie messen keine heutige Verbreitung. False Start sendete keinen Klartext, übersprang kein Zertifikat, nahm keine alte Sitzung wieder auf und benötigte keine eigene Server-Extension.