Session Ticket TLS 1.3 Membawa State Resumption Antar-Koneksi

Handshake TLS 1.3 yang selesai dapat menghasilkan lebih dari sekadar traffic key untuk koneksi yang sedang terbuka. Setelah handshake, server dapat menerbitkan NewSessionTicket yang memberi client material untuk mencoba resumption pada koneksi berikutnya. Koneksi baru itu dapat membuktikan kesinambungan dengan session TLS sebelumnya tanpa mengulang jalur certificate-based handshake yang sama.

Optimasi tersebut mengubah lokasi security state. Deployment yang mengaktifkan resumption tidak lagi hanya berurusan dengan sertifikat server dan key pada koneksi saat ini. Masa berlaku ticket, resumption secret, atribut autentikasi yang di-cache, ticket protection key, serta aturan untuk menerima koneksi hasil resumption ikut menjadi bagian dari boundary.

Ticket merepresentasikan asosiasi PSK

Pada TLS 1.3, resumption terintegrasi dengan mekanisme pre-shared key. Sebuah NewSessionTicket membentuk asosiasi antara nilai ticket dan PSK yang diturunkan dari resumption secret. Pada koneksi berikutnya, client dapat menempatkan identitas ticket di extension pre_shared_key pada ClientHello.

Implementasi ticket dapat memakai model yang berbeda. Server dapat menyimpan state dan menjadikan ticket sebagai key untuk lookup database, atau memasukkan state ke dalam nilai yang dilindungi secara kriptografis. Mekanisme resumption pada wire tidak mewajibkan semua deployment memakai model penyimpanan yang sama.

Perbedaan ini penting secara operasional. Ticket stateful bergantung pada record yang dipertahankan server. Ticket self-contained memindahkan lebih banyak tanggung jawab ke key yang melindungi state di dalamnya. Kehilangan atau rotasi key tersebut dapat membuat ticket yang masih beredar tidak dapat digunakan; mempertahankannya terlalu lama dapat membuat state resumption lama tetap diterima melebihi periode yang diinginkan.

Binder mengikat PSK ke handshake baru

Percobaan resumption bukan sekadar client menyerahkan ticket opaque lalu langsung mengirim application traffic. TLS 1.3 memakai PSK binder di ClientHello. Binder dihitung dari PSK dan sebagian handshake transcript, sehingga kepemilikan PSK terikat ke handshake yang sedang berlangsung.

Untuk PSK yang dibentuk melalui NewSessionTicket, hubungan itu juga mengaitkan handshake baru dengan key material yang diturunkan dari handshake sebelumnya. Server tetap harus memilih PSK yang dapat diterima dan melanjutkan TLS 1.3 key schedule secara benar.

Koneksi hasil resumption juga dapat memakai PSK bersama fresh (EC)DHE key establishment. Dalam mode tersebut, ephemeral key exchange yang baru ikut berkontribusi pada key koneksi baru. Karena itu, resumption tidak tepat digambarkan sebagai penggunaan ulang traffic key lama; TLS 1.3 menurunkan secret baru untuk setiap koneksi.

Masa berlaku ticket adalah jendela penerimaan

NewSessionTicket membawa nilai ticket_lifetime. TLS 1.3 membatasi masa berlaku yang diiklankan maksimal 604800 detik, atau tujuh hari, dan client tidak boleh menyimpan ticket melampaui batas tersebut. Server dapat menerapkan masa berlaku efektif yang lebih pendek.

Batas maksimum protokol bukan anjuran agar setiap ticket tetap valid selama tujuh hari. Masa berlaku yang sesuai bergantung pada security state yang dibawa resumption dan seberapa cepat state itu dapat menjadi usang.

Ticket berumur pendek mempersempit periode ketika state resumption lama masih dapat diajukan. Masa berlaku lebih panjang dapat meningkatkan peluang client yang kembali untuk melakukan resumption, tetapi juga memperpanjang interval ketika deployment harus mempertahankan mekanisme penerimaan yang sesuai.

TLS 1.3 juga memperingatkan agar keying material tidak diperpanjang tanpa batas dengan terus menerbitkan ticket baru dari session hasil resumption. Implementasi diharapkan membatasi total masa hidup keying material dengan mempertimbangkan faktor seperti masa berlaku sertifikat, revocation, dan waktu yang berlalu sejak signature sertifikat dilakukan secara online.

Resumption dapat mempertahankan state autentikasi yang sudah usang

TLS handshake membentuk autentikasi kriptografis, tetapi aplikasi sering menambahkan policy lain pada peristiwa tersebut. Sebuah koneksi dapat dikaitkan dengan akun, device posture, atribut client certificate, tenant, role, atau keputusan otorisasi lain di luar TLS key schedule.

Jika session hasil resumption mengandalkan atribut yang di-cache dari koneksi awal, atribut itu dapat menjadi usang sebelum ticket kedaluwarsa. Akun dapat dinonaktifkan. Role dapat berubah. Client certificate dapat masuk ke kondisi yang membuat jalur autentikasi baru menolaknya. Policy jaringan atau aplikasi juga dapat berubah secara independen dari TLS.

Boundary yang aman harus dinyatakan secara eksplisit: state yang diperlukan untuk otorisasi saat resumption harus tetap valid sepanjang jendela penerimaan atau diperiksa kembali ketika koneksi hasil resumption dibentuk. Ticket tidak semestinya diam-diam mengubah keputusan otorisasi pada satu titik waktu menjadi hak akses jangka panjang.

Masalah ini terlihat jelas pada protokol yang menggabungkan TLS resumption dengan autentikasi client. Handshake hasil resumption dapat melewati pekerjaan yang dilakukan pada full handshake awal, sehingga aplikasi perlu mempertahankan atau memperbarui konteks yang cukup untuk mengambil keputusan otorisasi saat ini secara aman.

Ticket self-contained menjadikan rotasi key sebagai kontrol keamanan

Ticket self-contained dapat memungkinkan server memulihkan state resumption tanpa menyimpan record untuk setiap client. Hal ini menghilangkan kebutuhan state database per-ticket, tetapi tidak menghilangkan secret state di sisi server. Server tetap memerlukan key material untuk mengautentikasi dan, jika desainnya memerlukan, mengenkripsi isi ticket.

Masa hidup protection key tersebut memengaruhi setiap ticket yang dilindunginya. Jika key bocor, dampaknya dapat mencakup kumpulan ticket yang masih diterima dengan key itu. Jika key dihapus, server yang bergantung padanya tidak lagi dapat memulihkan ticket tersebut.

Rotasi karena itu memerlukan dua horizon waktu: periode penerbitan ticket dengan key aktif dan periode terkendali untuk menerima ticket yang dilindungi key yang baru dipensiunkan. Kumpulan key penerimaan sebaiknya tidak lebih luas daripada kebutuhan policy ticket.

Pada server fleet, pertimbangan yang sama berubah menjadi persoalan distribusi. Node yang diharapkan dapat menerima ticket satu sama lain memerlukan protection state yang kompatibel. Distribusi state tersebut memperluas sistem yang dapat memengaruhi keamanan resumption, sehingga access control dan prosedur rotasi ticket key patut diperlakukan setara dengan secret autentikasi lain.

Banyak ticket bukan satu identitas yang dapat dipakai terus-menerus

Server dapat mengirim beberapa pesan NewSessionTicket dalam satu koneksi. TLS 1.3 menurunkan PSK berbeda untuk setiap ticket dengan ticket_nonce yang berbeda. Beberapa ticket dapat mendukung koneksi paralel dan connection racing tanpa memaksa satu nilai ticket melayani semua koneksi berikutnya.

Penggunaan ulang ticket juga memiliki biaya privasi. Ticket yang sama dapat memberi passive observer sinyal untuk mengorelasikan koneksi. Implementasi dapat mengurangi paparan ini dengan menerbitkan dan menggunakan ticket sesuai panduan protokol, bukan memperlakukan satu ticket sebagai identifier client permanen.

Ticket juga perlu dipisahkan dari identitas aplikasi. Ticket adalah credential untuk TLS resumption, bukan token akun stabil, identifier analytics, atau pengganti model application session.

0-RTT menambahkan replay boundary yang terpisah

Session ticket juga dapat mengiklankan izin untuk early data. Fitur ini berbeda dari resumption 1-RTT biasa. Dengan 0-RTT, client dapat mengirim application data sebelum handshake baru selesai, sehingga muncul sifat replay yang tidak dimiliki application data biasa setelah handshake.

Mengaktifkan resumption tidak mewajibkan 0-RTT. Deployment dapat menerima resumed handshake sambil menolak early data. Jika early data diaktifkan, operasi aplikasi yang diterima pada fase itu memerlukan desain yang memperhitungkan replay; autentikasi ticket saja tidak membuat early request aman untuk dieksekusi lebih dari sekali.

Memisahkan kedua keputusan tersebut mencegah fitur performa memperluas semantik aplikasi secara diam-diam. Penerimaan ticket menentukan apakah hubungan TLS sebelumnya dapat menyumbangkan PSK ke handshake baru. Policy early data menentukan apakah application byte boleh diproses sebelum handshake mencapai titik penyelesaian normal.

Policy resumption berada di sisi yang sama dengan policy sertifikat

Rotasi sertifikat, penanganan revocation, dan aturan autentikasi client lazim ditinjau sebagai kontrol keamanan eksplisit. Session resumption perlu mendapat perlakuan yang sama karena mekanisme ini dapat membawa kesinambungan autentikasi melewati momen ketika kontrol tersebut seharusnya dijalankan kembali.

Policy praktis menetapkan masa berlaku maksimum ticket, usia maksimum state autentikasi yang mendasarinya, kondisi yang memaksa full handshake, model penyimpanan atau perlindungan ticket, jadwal rotasi ticket key, serta apakah 0-RTT diterima. Policy juga menetapkan perilaku saat ticket tidak dikenal, kedaluwarsa, atau dilindungi key yang sudah dipensiunkan.

Protokol mengizinkan server menolak percobaan resumption dan melanjutkan dengan non-PSK handshake jika memungkinkan. Fallback tersebut berguna: penolakan state resumption yang usang tidak harus berarti penolakan client secara keseluruhan.

Session ticket TLS 1.3 mengurangi pekerjaan handshake berulang dengan membawa kesinambungan yang dibatasi secara cermat ke koneksi berikutnya. Properti keamanannya bergantung pada kesinambungan yang tetap lebih sempit daripada policy yang diwakilinya. Kedaluwarsa ticket, rotasi key, pemeriksaan otorisasi yang baru, dan penanganan early data yang disengaja menjaga agar resumption tidak bertahan lebih lama daripada keputusan trust yang membentuknya.

Referensi

Cybersecurity TLS 1.3 Session Resumption Kriptografi