Koneksi TLS 1.3 yang di-resume dapat membawa byte aplikasi sebelum server menyelesaikan handshake baru. Pengurangan latensi ini mengubah batas keamanan: early data tetap terlindungi saat transit, tetapi protokol tidak memberinya properti replay yang sama dengan data aplikasi biasa setelah handshake.

Perbedaan ini penting ketika endpoint memetakan satu request ke operasi yang mengubah state. Flight early data yang tertangkap dapat disajikan kembali dalam kondisi yang membuat server menerimanya, sehingga confidentiality dan integrity di jalur jaringan tidak berarti eksekusi hanya sekali.

Early traffic key berasal dari state resumption

Setelah koneksi TLS 1.3 berhasil, server dapat menerbitkan NewSessionTicket. Client kemudian memakai PSK terkait pada resumed handshake. Jika ticket mengizinkan early data, client dapat menurunkan early traffic key dan mengirim byte 0-RTT bersama flight pertamanya.

koneksi sebelumnya
    │
    └── NewSessionTicket + state PSK
                │
                ▼
resumed connection
ClientHello + early data ──────────► server
                         ◄────────── ServerHello ... Finished
client Finished ───────────────────►
data aplikasi setelah handshake

Server dapat menolak early data sambil tetap melanjutkan handshake. Penerimaan early data karena itu terpisah dari keberhasilan resumption. Aplikasi juga memerlukan perilaku untuk early data yang ditolak; mengirimnya kembali setelah handshake hanya valid ketika semantik operasi memang mengizinkan retry.

Enkripsi tidak menjamin eksekusi tunggal

TLS mengautentikasi record terenkripsi, tetapi rangkaian early data yang valid dapat di-replay sebagai satu rangkaian. Penyerang tidak perlu mendekripsi atau mengubah request untuk memicu penyajian kedua.

Pertimbangkan request HTTP dengan sesi terautentikasi dan kebijakan aplikasi yang mengizinkan mutasi:

POST /api/credits/transfer HTTP/1.1
Host: service.example
Content-Type: application/json

{"destination":"account-b","amount":25}

Mengirim operasi semacam itu sebagai early data tidak aman kecuali aplikasi memiliki mekanisme independen yang membuat eksekusi duplikat tidak berbahaya atau dapat dideteksi. Transport dapat memverifikasi bahwa byte tersebut sesuai dengan early traffic yang valid; transport tidak dapat menentukan apakah transfer kedua secara semantik merupakan duplikat yang aman.

Hal ini juga berbeda dari duplikasi packet di dalam satu koneksi. Pemrosesan TLS record memiliki sequence state untuk sebuah koneksi. Risiko replay 0-RTT melintasi percobaan koneksi dan konteks resumption.

Kontrol replay server memiliki batas deployment

TLS 1.3 mengizinkan server menerapkan mekanisme anti-replay, tetapi mekanisme tersebut membawa asumsi state dan topologi. Server dapat mencatat informasi resumption yang baru dipakai lalu menolak pemakaian ulang. Pada layanan terdistribusi, keputusan itu mungkin memerlukan shared state atau routing yang menjaga resumption terkait tetap berada dalam satu domain kontrol replay.

Cluster dengan replay cache independen menunjukkan batas tersebut:

             ┌── edge A ── replay cache A
client ──────┤
             └── edge B ── replay cache B

penyajian pertama → edge A mencatatnya
penyajian kedua   → edge B tidak memiliki catatan yang cocok

Hasil tepatnya bergantung pada desain ticket, distribusi key, routing, dan implementasi anti-replay. TLS tidak otomatis membuat front end yang beroperasi independen berbagi state replay.

Masa berlaku ticket juga bukan jaminan anti-replay. Lifetime yang pendek mempersempit periode penerimaan material resumption, tetapi tidak dengan sendirinya memaksakan pemakaian satu kali di dalam periode tersebut.

Semantik aplikasi tetap menjadi gerbang terakhir

Deployment yang kokoh memperlakukan kelayakan 0-RTT sebagai keputusan aplikasi, bukan optimasi TLS yang diterapkan menyeluruh. Operasi yang aman untuk diulang lebih mudah menjadi kandidat. Operasi dengan side effect eksternal, transisi authorization, counter, pembelian, pengiriman pesan, atau mutasi yang tidak dapat dibatalkan memerlukan perlakuan lebih kuat.

Aplikasi dapat memakai idempotency key untuk operasi tertentu:

Idempotency-Key: 7c3d...unique-value
        │
        ▼
server-side operation record
        │
        ├── unseen → execute and record result
        └── seen   → return recorded result

Mekanisme itu memiliki persyaratan sendiri. Key harus diikat ke principal terautentikasi dan operasi yang relevan, disimpan selama interval yang sesuai, serta diproses secara atomik bersama perubahan state. Identifier dari client tanpa penegakan keunikan di sisi server bukan perlindungan replay.

Kebijakan lain lebih sederhana: terima early data hanya untuk kelas request yang secara eksplisit ditandai aplikasi sebagai toleran terhadap replay, lalu tunda seluruh data aplikasi lain sampai handshake selesai. Nama HTTP method dapat membantu kebijakan itu, tetapi klasifikasi method saja tidak cukup ketika endpoint melanggar semantik yang diharapkan atau request yang secara nominal aman memicu side effect.

Konteks autentikasi dapat berubah melintasi batas

Early data dikirim sebelum handshake baru selesai. Konteks keamanannya terikat pada resumption PSK dan koneksi asal, bukan pada seluruh properti yang mungkin baru tersedia kemudian dalam handshake baru.

Deployment yang mengandalkan client authentication baru, state authorization yang dievaluasi ulang, atau kebijakan spesifik koneksi tidak dapat menganggap pemeriksaan tersebut sudah berlaku pada byte 0-RTT. Aplikasi dan lapisan terminasi TLS harus sepakat mengenai request yang boleh melintasi batas tersebut serta atribut identitas yang valid pada titik itu.

Kondisi ini sangat penting ketika TLS berakhir di reverse proxy. Jika proxy meneruskan early request ke origin, origin memerlukan signal yang dapat dipercaya atau kebijakan proxy yang ditegakkan; tanpa itu, komponen yang membuat keputusan perubahan state mungkin tidak mengetahui bahwa request tiba sebagai early data yang dapat di-replay.

Kebijakan latensi dan keamanan harus memakai batas yang sama

0-RTT menghapus waktu tunggu dari bagian sempit proses pembentukan koneksi. Fitur ini tidak mengubah operasi sensitif terhadap replay menjadi aman terhadap replay. Batas deployment yang berguna karena itu harus eksplisit: resumption dapat diaktifkan secara luas sementara penerimaan early data tetap dibatasi oleh semantik request, cakupan kontrol replay, dan persyaratan autentikasi terkini.

Ketika layanan tidak dapat mempertahankan state replay yang sesuai atau tidak dapat mengklasifikasikan operasi sebagai aman saat disajikan lebih dari sekali, penolakan early data untuk operasi tersebut mempertahankan asumsi eksekusi yang lebih kuat dari traffic setelah handshake. Keuntungan latensi hanya dipakai pada area tempat aplikasi dapat menerima properti replay yang lebih lemah tanpa mengubah hasil keamanan.

TLS 1.3 0-RTT Replay Keamanan Transport