TLS Early Data Menukar Latensi Handshake dengan Risiko Replay

Client yang kembali dapat memiliki cukup state dari koneksi TLS 1.3 sebelumnya untuk mengirim application data bersama flight handshake pertamanya. Ini menghilangkan satu round trip dari critical path untuk traffic yang memenuhi syarat, tetapi juga mengubah properti keamanan yang sering dianggap implisit oleh aplikasi: encrypted transport tidak lagi berarti sebuah request hanya dapat muncul satu kali di seluruh koneksi.

TLS 1.3 early data, yang umum disebut 0-RTT, dilindungi menggunakan key yang diturunkan dari pre-shared key yang terkait dengan session sebelumnya atau PSK yang disediakan secara eksternal. Server belum memberikan fresh handshake state ketika byte tersebut dikirim. Akibatnya, early data memiliki replay property yang lebih lemah daripada application data biasa yang dikirim setelah handshake.

Boundary operasional karena itu bergeser ke layer yang lebih tinggi. TLS dapat melindungi early byte dari passive disclosure dan modification sesuai negotiated construction, tetapi aplikasi yang menerima state-changing request pada fase tersebut harus memperhitungkan kemungkinan delivery duplikat.

Fresh server state datang terlalu terlambat untuk mengikat first flight

Ordinary TLS 1.3 application traffic diturunkan dari handshake yang memasukkan fresh server input. Early data berbeda. Client yang menawarkan PSK sesuai dapat menurunkan early traffic key sebelum menerima ServerHello baru dari server, dan inilah yang memungkinkan transmission pada first flight.

Pengurangan latency tersebut membuat application byte pertama tidak dapat bergantung pada fresh per-connection server state. Karena itu TLS 1.3 tidak menyediakan cross-connection non-replay guarantee untuk 0-RTT data. Attacker yang dapat menangkap early-data flight yang valid dapat mencoba menyajikannya kembali pada kondisi ketika server menerima PSK terkait dan early data.

Ini tidak sama dengan memalsukan request baru. Replay saja tidak memberi attacker kemampuan membentuk plaintext arbitrer. Risikonya adalah duplikasi terhadap request yang memang sebelumnya dibuat client sah. Untuk operasi seperti transfer saldo, pengajuan pembelian, one-time action, atau mutation dengan external side effect, duplikasi saja sudah dapat menimbulkan kegagalan keamanan atau integritas.

Penerimaan TLS dan keamanan aplikasi adalah keputusan terpisah

Pada layer TLS, server menerima atau menolak early data yang ditawarkan. Acceptance bergantung pada kondisi protocol yang terkait dengan PSK dan negotiated parameter. Hal itu tidak membuktikan bahwa setiap application request yang dibawa record tersebut aman dieksekusi lebih dari sekali.

Perbedaan ini sangat penting untuk HTTP. TLS terminator dapat menerima 0-RTT karena koneksi memenuhi transport requirement sementara origin memiliki pengetahuan resource-specific bahwa request tertentu tidak boleh diproses dalam kondisi replay exposure.

HTTP mendefinisikan request field Early-Data untuk membawa state tersebut melintasi intermediary hop. Gateway yang meneruskan request yang mungkin diproses dari early data dapat menandainya sehingga origin tetap mengetahui konteks yang relevan setelah TLS termination. Sinyal ini mencegah transport boundary menghapus informasi yang dibutuhkan untuk application decision.

Untuk request yang tidak aman diproses dalam replay exposure, HTTP juga mendefinisikan status code 425 Too Early. Retry setelah response tersebut dikirim setelah handshake, bukan sebagai early data. Ini memindahkan request dari konteks 0-RTT yang lebih lemah ke ordinary post-handshake processing tanpa mengharuskan origin menolak seluruh koneksi TLS.

Label method tidak sepenuhnya menjelaskan konsekuensi replay

Semantik HTTP method menyediakan filter awal yang berguna, tetapi bukan replay policy yang lengkap. Request yang secara nominal safe tetap dapat memicu application-specific side effect, komputasi mahal, audit event, konsumsi rate limit, cache population, atau interaksi dengan backend yang perilakunya tidak sepenuhnya observasional.

Sebaliknya, aplikasi kadang dapat membuat mutation tahan terhadap duplicate delivery dengan mengikatnya ke stable operation identifier dan menegakkan uniqueness pada authoritative state transition. Itu adalah properti aplikasi, bukan properti yang diciptakan oleh 0-RTT.

Replay tolerance karena itu harus dinilai pada operation boundary tempat efek menjadi durable. Proxy rule yang hanya berdasarkan nama method dapat melewatkan side effect yang tersembunyi di balik GET, sementara larangan menyeluruh terhadap semua request non-GET dapat membuang peluang performa yang valid tanpa mengekspresikan invariant sebenarnya.

Distributed anti-replay state mengubah trade-off availability

TLS 1.3 menjelaskan langkah server-side yang dapat mengurangi replay exposure, termasuk mencatat informasi terkait early data yang diterima. Pada single process, mempertahankan state seperti ini relatif langsung. Fleet membuat boundary tersebut lebih rumit.

Jika beberapa edge instance dapat menerima resumption material yang sama, replay detection mungkin memerlukan coordinated state, ticket scope yang dibatasi, atau routing property yang menjaga acceptance decision tetap konsisten. Coordination menambah storage, synchronization, failure handling, dan availability cost. Coordination yang longgar dapat membuat instance terpisah sama-sama menerima captured flight yang sama.

Desain anti-replay yang ketat juga dapat menimbulkan false rejection selama failover atau partition event. Pilihan engineering bukan sekadar security enabled versus disabled; keputusan sebenarnya adalah di mana replay state berada, berapa lama state itu authoritative, dan apa yang terjadi ketika state tersebut tidak dapat dikonsultasikan.

Untuk banyak state-changing HTTP operation, menolak early processing lebih sederhana daripada membangun globally consistent replay tracking. Optimasi latency tetap dapat digunakan untuk traffic yang duplicate execution-nya dapat diterima, sementara operasi sensitif fallback ke completed handshake.

Retry behavior dapat menggandakan efek tanpa attacker

Replay exposure tidak terbatas pada malicious retransmission. Early data dapat ditolak server, setelah itu client dapat mengirim ulang application data ketika handshake selesai. Specification TLS menyerahkan keputusan retransmission kepada aplikasi karena automatic resend dapat melanggar asumsi aplikasi.

Hal ini menambahkan boundary kedua di sekitar acknowledgment. Client yang tidak dapat memastikan apakah early request sempat mencapai application processing tidak boleh menganggap transport-level rejection sebagai bukti bahwa tidak ada efek yang terjadi. Sistem yang melakukan retry terhadap mutation membutuhkan idempotency mechanism yang scope-nya mencapai durable operation, bukan mengandalkan connection state sebagai uniqueness guarantee.

Masalah yang sama muncul ketika gateway melakukan retry atas nama client. Early-data signaling HTTP dan response 425 mengoordinasikan behavior tersebut, tetapi tidak membuat operasi arbitrer menjadi idempotent. Origin tetap menjadi komponen dengan konteks cukup untuk memutuskan apakah duplicate execution dapat diterima.

Early data adalah scoped optimization, bukan default transport property

TLS 1.3 tidak mewajibkan aplikasi menggunakan early data. Deployment dapat mendukung session resumption sambil menolak 0-RTT sepenuhnya, sehingga tetap memperoleh sebagian besar manfaat authentication dan key establishment dari resumed session tanpa menerima pre-handshake application byte.

Jika 0-RTT diaktifkan, nilainya paling tinggi ketika request semantics dan replay policy eksplisit di setiap hop. TLS termination, load balancing, retry, origin processing, dan durable state change semuanya berpartisipasi dalam keputusan tersebut. Jika salah satu layer menghapus early-data context atau menganggap encryption berarti uniqueness, optimasi latency melewati trust boundary tanpa membawa security condition yang membuatnya aman.

Trade-off utamanya sempit tetapi penting: early data menghapus handshake latency dengan bertindak sebelum fresh server state dapat mengikat request pada satu koneksi. Sistem yang menerima optimasi ini harus menyediakan replay tolerance atau replay control pada layer tempat duplicated effect benar-benar berarti.