TLS 1.3: 0-RTT, Data Awal, dan Pelanjutan Sesi

TLS 1.3 (RFC 8446, 2018) merancang ulang jabat tangan TLS untuk mengurangi latensi dan menghapus kode warisan yang tidak diperlukan. Jabat tangan TLS 1.3 penuh selesai dalam 1-RTT: klien mengirim ClientHello dengan key_shares yang didukung (kunci publik ECDH sementara) pada pertukaran pertama; server merespons dengan ServerHello, key_share miliknya, ekstensi terenkripsi, sertifikat, dan Finished — semuanya dalam satu respons. Klien mengirim Finished miliknya dan dapat langsung mengirim data aplikasi. Dibandingkan jabat tangan TLS 1.2 yang memerlukan 2-RTT, ini memangkas separuh waktu penyiapan koneksi untuk sesi baru.

TLS 1.3 menggunakan HKDF (Fungsi Derivasi Kunci Berbasis HMAC) dengan jadwal kunci terstruktur. Setelah pertukaran kunci ECDHE, rahasia bersama menjadi masukan hierarki: Extract(early_secret, DHE) -> handshake_secret; lalu Extract(handshake_secret, 0) -> master_secret. Dari nilai-nilai ini, HKDF-Expand-Label menurunkan kunci terpisah untuk lalu lintas jabat tangan klien dan server, lalu lintas aplikasi, serta penyambungan kembali. Pemisahan yang jelas ini memastikan bahwa kompromi pada satu lapisan kunci tidak memengaruhi lapisan lainnya — peningkatan signifikan dibandingkan derivasi kunci berbasis PRF TLS 1.2 yang lebih tidak terstruktur.

Penyambungan kembali sesi TLS 1.3 menggunakan Kunci yang Dibagikan Sebelumnya (PSK) yang diturunkan dari sesi sebelumnya. Setelah jabat tangan selesai, server mengirim pesan NewSessionTicket yang berisi identitas PSK dan nilai tiket (blok data terenkripsi yang menyimpan rahasia penyambungan kembali). Saat tersambung kembali, klien menyertakan identitas PSK dalam ClientHello. Jika server mengenalinya, kedua pihak menurunkan kunci sesi baru dari PSK dan ECDHE baru, sehingga mencapai penyambungan kembali 1-RTT dengan kerahasiaan ke depan. Tiket memiliki masa berlaku yang dapat dikonfigurasi (biasanya 24 jam) dan harus dienkripsi dengan kunci sisi server yang diputar secara berkala.

TLS 1.3 memungkinkan data awal 0-RTT untuk sesi yang disambungkan kembali. Klien menggunakan PSK dari sesi sebelumnya untuk mengenkripsi data aplikasi yang dikirim pada pertukaran pertama — sebelum ada konfirmasi dari server. Ini menghilangkan satu perjalanan bolak-balik untuk koneksi ke server yang pernah dikunjungi, sehingga memberikan latensi nyaris nol untuk koneksi berulang. Server mengumumkan dukungan 0-RTT dalam NewSessionTicket melalui ekstensi early_data dengan max_early_data_size. Server harus memiliki mekanisme untuk menerima atau menolak data 0-RTT dan menandakan penerimaan dalam EncryptedExtensions.

Data 0-RTT memiliki keterbatasan keamanan mendasar: data ini rentan terhadap serangan pemutaran ulang. Penyerang di jalur yang menangkap pertukaran pertama dapat memutarnya ulang ke server, sehingga server memproses data awal itu lagi. Hal ini merupakan sifat bawaan — server belum mengirim pesan apa pun, sehingga belum ada nilai kesegaran yang berasal dari server. Mitigasinya: (1) Tiket sekali pakai (server membatalkan tiket setelah penggunaan pertama dengan cache terdistribusi seperti memcached/Redis). (2) Tiket berbatas waktu (menolak 0-RTT setelah jangka waktu singkat, misalnya 5 detik). (3) Idempotensi tingkat aplikasi (hanya mengizinkan 0-RTT untuk operasi yang aman dan setara dengan GET).

Mekanisme paling tangguh untuk mencegah pemutaran ulang 0-RTT adalah tiket sesi sekali pakai. Server memelihara penyimpanan "tiket yang telah digunakan" (cache terdistribusi dalam penerapan multi-server). Saat data 0-RTT tiba, server memeriksa apakah tiket tersebut pernah dilihat sebelumnya — jika ya, server menolak data awal dan kembali ke 1-RTT. Jika belum, server menandai tiket sebagai telah digunakan dan memproses data awal. Agar benar, semua server dalam satu klaster harus berbagi cache tiket yang telah digunakan. Redis dengan TTL singkat yang sesuai dengan masa berlaku tiket merupakan penerapan yang umum. Tanpa mekanisme ini, 0-RTT tidak aman untuk operasi non-idempoten seperti pembayaran.

Penyambungan kembali PSK TLS 1.3 tanpa DHE tidak memiliki kerahasiaan ke depan untuk sesi yang disambungkan kembali — jika PSK kemudian disusupi, seluruh lalu lintas sesi yang disambungkan kembali dapat didekripsi. Untuk mempertahankan kerahasiaan ke depan, TLS 1.3 mendukung PSK dengan DHE: ClientHello menyertakan identitas PSK dan key_share baru. Server menggabungkan PSK dan keluaran ECDHE untuk menurunkan kunci sesi. Bahkan jika PSK disusupi, kontribusi ECDHE memastikan lalu lintas sebelumnya tetap terlindungi. RFC 8446 merekomendasikan PSK dengan DHE untuk semua kasus penyambungan kembali yang memerlukan kerahasiaan ke depan.

TLS 1.2 memiliki lebih dari 300 kombinasi rangkaian sandi, dan banyak di antaranya tidak aman. TLS 1.3 menguranginya menjadi 5 rangkaian sandi, semuanya menggunakan AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, dan TLS_AES_128_CCM_8_SHA256. Pertukaran kunci dan autentikasi dinegosiasikan secara terpisah melalui ekstensi supported_groups dan signature_algorithms. Pemisahan ini menghilangkan kompleksitas kombinatorial TLS 1.2 dan memastikan setiap koneksi TLS 1.3 menggunakan enkripsi terautentikasi.

Dalam praktiknya, 0-RTT paling berguna untuk koneksi HTTP/2 ketika klien mengulangi permintaan GET (aman dan idempoten) ke server yang pernah dikunjungi. Peramban menerapkan 0-RTT dengan hati-hati: Chrome mengaktifkannya untuk metode HTTP yang aman; permintaan POST tidak pernah dikirim sebagai data 0-RTT. HTTP/3 melalui QUIC mengintegrasikan TLS 1.3 secara bawaan — 0-RTT QUIC menggunakan kembali mekanisme TLS 1.3. Dalam QUIC, 0-RTT juga memulihkan parameter transportasi (kontrol aliran, batas aliran) dari sesi sebelumnya, sehingga makin mengurangi beban penyiapan, bukan hanya pada lapisan TLS.

TLS 1.3 menyertakan mekanisme untuk mencegah serangan penurunan versi. Bidang random ServerHello berisi nilai penanda saat TLS 1.3 dinegosiasikan: 8 bita terakhir diatur ke nilai tetap (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 untuk pengembalian ke TLS 1.2). Klien yang mendukung TLS 1.3 memeriksa penanda ini ketika server menegosiasikan TLS 1.2, sehingga mendeteksi upaya penurunan versi aktif. Selain itu, hash transkrip Finished mencakup seluruh jabat tangan, termasuk negosiasi versi, sehingga setiap manipulasi dapat dideteksi. SCSV (Nilai Rangkaian Sandi Penanda) seperti TLS_FALLBACK_SCSV menyediakan sinyal penurunan versi terpisah untuk versi TLS yang lebih lama.

Penerapan TLS 1.3 memerlukan perhatian terhadap beberapa detail operasional. Kunci enkripsi tiket sesi harus diputar (biasanya setiap 24 jam) dan disinkronkan di seluruh klaster server agar penyambungan kembali dapat dilakukan ke server mana pun. Kunci dekripsi tiket lama harus dipertahankan selama masa berlaku tiket untuk menghindari kegagalan jabat tangan yang tidak semestinya. Penyertaan OCSP lebih penting dalam TLS 1.3 karena memerlukan satu perjalanan bolak-balik lebih sedikit untuk memeriksa status sertifikat. Penyeimbang beban harus meneruskan ClientHello TLS 1.3 tanpa perubahan — beberapa perangkat perantara lama merusak ekstensi yang tidak dikenal, sehingga memerlukan mode kompatibilitas.

Mengapa data awal 0-RTT rentan terhadap serangan pemutaran ulang dalam TLS 1.3?

TLS 1.3 mencapai jabat tangan penuh 1-RTT dan penyambungan kembali 0-RTT melalui tiket sesi PSK. Derivasi kunci menggunakan HKDF dengan jadwal terstruktur yang menghasilkan kunci terpisah untuk setiap lapisan lalu lintas. Data awal 0-RTT menghilangkan satu perjalanan bolak-balik, tetapi rentan terhadap pemutaran ulang — hal ini dimitigasi dengan tiket sekali pakai dan pembatasan 0-RTT pada operasi idempoten. PSK dengan DHE mempertahankan kerahasiaan ke depan untuk penyambungan kembali. TLS 1.3 membatasi rangkaian sandi menjadi 5 opsi AEAD, sehingga menghilangkan kombinasi lama yang tidak aman. Pencegahan penurunan versi menggunakan nilai penanda dalam bidang random server.