A TLS 1.3 egyik csábító ígérete, hogy a visszatérő látogató első HTTP-kérését már a TLS-kézfogás befejezése előtt elküldheti. Egy hálózati körrel kevesebb késleltetés mobilon vagy távoli régióból mérhető nyereség. Csakhogy az így elküldött kérésre nem ugyanazok a biztonsági garanciák érvényesek, mint egy rendes kapcsolatra. A 0-RTT-t ezért nem teljesítménykapcsolóként, hanem HTTP-szemantikai döntésként érdemes kezelni.
Mit spórol meg a 0-RTT?
Normál, új TLS-kapcsolatnál a kliens elküldi a ClientHello üzenetet, megvárja a szerver válaszát, és csak utána küld alkalmazási adatot. A TLS 1.3 early data ehhez képest egy korábbi kapcsolatból kapott session ticketre épít: a kliens a ClientHello mellé rögtön odateszi az első HTTP-kérést. Nem új látogató gyorsítása ez; csak akkor működhet, ha a kliensnek van használható, korábban kapott ticketje.
A név kicsit félrevezető. A „0” nem azt jelenti, hogy nincs kézfogás, hanem azt, hogy az első alkalmazási adat elküldéséhez nem kell megvárni egy round tripet. A szerver végül elutasíthatja az early datát, ilyenkor a kliensnek a kérést a szokásos, 1-RTT kapcsolaton újra el kell küldenie.
A rejtett ár: a kérés ismételhető
Az early data kulcsa olyan korábbi titokból származik, amelyhez a szerver még nem adott friss, kapcsolatspecifikus hozzájárulást. Emiatt a TLS 1.3 specifikáció nem ígér kapcsolatközi replay-védelmet: aki rögzíti az early adatot, elvben új kapcsolaton ismét elküldheti. A forgalom továbbra is titkosított; itt nem adatlopásról, hanem a szerver által kétszer végrehajtott műveletről van szó.
Ez klaszterben válik igazán kényelmetlenné. A ticketet elfogadó edge A és edge B nem feltétlenül oszt meg azonnal egy globális „ezt az early datát már láttam” állapotot. A TLS-specifikáció enged anti-replay megoldásokat – például friss ClientHello-k rögzítését –, de az erősen konzisztens, több régiós állapot költsége ütközik azzal az optimalizálással, amiért a 0-RTT-t bekapcsoltuk. A specifikáció külön kiemeli, hogy még idempotens műveletek ismétlése is okozhat erőforrás-kimerítést.
A GET nem automatikusan biztonságos
Az HTTP early data szabályai alaphelyzetben a safe metódusokat engedik, az unsafe metódusokat tiltják. De a vonatkozó RFC rögtön hozzáteszi: safe metódus is okozhat mellékhatást. Ez a rész könnyen elvész a „csak GET” leegyszerűsítésben.
GET /unsubscribe?token=…rossz tervezés, de a valóságban létező minta: ismételve is állapotot módosít.GET /download/reportlehet idempotens, de minden futtatása drága lekérdezést vagy exportgenerálást indíthat.- Egy olvasottságot, auditot vagy rate-limit számlálót frissítő GET üzleti értelemben már nem mellékhatás-mentes.
Na, ezt nem tudtam: a HTTP 0-RTT-nél még a kizárólag GET-re szorítás sem elégséges policy. Endpointszinten kell eldönteni, hogy egy kérés tetszőleges számú ismételt végrehajtása elfogadható-e. A „valószínűleg nem történik meg” nem jó válasz, mert a replay épp az a fenyegetési modell, amelyet a protokoll megenged.
Mi a 425 szerepe?
Az origin nem mindig látja a TLS-kézfogást: CDN vagy reverse proxy állhat előtte. Az Early-Data: 1 fejléc ezért továbbadja, hogy a kérés egy korábbi hopon early dataként ment át. Ha az endpoint nem vállalja a replayt, 425 Too Early választ adhat. A kliens vagy a köztes szereplő ezután befejezett TLS-kapcsolaton ismétli meg a kérést; a 425 nem cache-elhető alapértelmezésben.
A gyakorlatban ezt a határt jellemzően a TLS-t termináló réteg kezeli. NGINX-ben az ssl_early_data direktíva és a $ssl_early_data változó erre ad építőelemet. Ettől még nem lesz kész a policy: a proxy csak azt tudja, hogy a kérés korai volt; azt, hogy egy adott üzleti endpoint kétszeri futása belefér-e, az alkalmazás ismeri.
Mikor kapcsolnám be?
Publikus, tényleg olvasási célú útvonalaknál – például cache-elhető HTML-nél, statikus konfigurációnál vagy egy mellékhatásmentes keresési kérésnél – jó eszköz lehet, ha a CDN és az origin dokumentáltan kezeli az early data jelzését. Írási API-k, hitelesített állapotváltások, fizetés, jelszó-visszaállítás és költséges, számlálót módosító GET-ek előtt nem engedném át.
Productionben ezért alapértelmezésként inkább kikapcsolva hagynám, majd mért késleltetési nyereség és endpointlista alapján, szűken engedélyezném. A 0-RTT akkor jó optimalizálás, ha a rendszer már replay-tűrő; nem arra való, hogy utólag azzá próbáljuk tenni.