TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake

Server TLS dapat memiliki private key yang valid dan menyajikan sertifikat yang membentuk chain ke root tepercaya, tetapi bukti status revokasinya tidak tersedia. OCSP stapling biasa tidak selalu mengubah kondisi tersebut menjadi kegagalan: client dapat meminta informasi status, tetapi dalam protokol stapling dasar server masih diperbolehkan tidak mengirim respons.

Sifat opsional ini menciptakan batas keamanan. Intermediary aktif yang mampu menghalangi akses ke OCSP responder dapat memanfaatkan kebijakan client yang menerima pemeriksaan revokasi yang tidak konklusif. Ekstensi TLS Feature dari RFC 7633 mengubah sertifikat itu sendiri sehingga fitur TLS tertentu menjadi syarat penggunaan yang dapat diterima. Untuk OCSP stapling, sertifikat dapat menyatakan bahwa client yang patuh harus menerima bukti status yang diminta.

Hasilnya adalah trade-off ketersediaan yang disengaja. Deployment yang menggunakan mekanisme ini tidak lagi memperlakukan status yang hilang sebagai kondisi netral. Kegagalan menyediakan bukti stapled yang dapat diterima dapat membuat sertifikat yang secara kriptografis valid menjadi tidak dapat digunakan.

Stapling membawa bukti revokasi ke dalam handshake

OCSP memungkinkan relying party mendapatkan informasi status bertanda tangan mengenai sebuah sertifikat dari OCSP responder. Query langsung dari client menambah biaya operasional: ada dependency jaringan tambahan, aktivitas pemeriksaan sertifikat terekspos ke responder, dan pembentukan koneksi dapat menjadi lebih lambat.

Negosiasi status sertifikat TLS memungkinkan server mengambil respons OCSP lalu mengirimkannya bersama handshake TLS. Pada TLS 1.2 dan sebelumnya, RFC 6066 mendefinisikan negosiasi status_request dan pesan handshake CertificateStatus. Pada TLS 1.3, status sertifikat dibawa dalam ekstensi status_request yang terkait dengan CertificateEntry.

Server bukan pihak yang menyatakan sendiri bahwa sertifikatnya valid. Server hanya membawa respons OCSP bertanda tangan dari responder yang relevan. Client tetap harus memvalidasi respons tersebut berdasarkan kebijakan status sertifikatnya, termasuk signature, kesesuaian dengan sertifikat, status, dan batas freshness.

Arsitektur ini menghilangkan kebutuhan setiap client menghubungi responder pada setiap koneksi. Sebagai gantinya, server memikul tanggung jawab menjaga material status yang masih layak di setiap titik terminasi TLS.

Stapling dasar tidak membuat ketiadaan menjadi bermakna

Negosiasi stapling asli bersifat opsional. RFC 6066 mengizinkan server yang menerima permintaan status untuk mengirim respons yang sesuai, tetapi juga mengizinkan server tidak mengirim CertificateStatus.

Perilaku ini mendukung deployment bertahap. Client dapat mengiklankan dukungan tanpa merusak server yang belum melakukan stapling. Namun, akibatnya ketiadaan respons saja tidak dapat membedakan beberapa kondisi: stapling tidak didukung, kegagalan server sementara, cache status sudah basi, penghilangan yang disengaja, atau interferensi jaringan.

Ambiguitas ini penting ketika client menggunakan kebijakan revokasi soft-fail. Jika ketidakmampuan memperoleh status masih diterima, penyerang tidak perlu memalsukan respons OCSP good yang bertanda tangan. Cukup mencegah client memperoleh status yang konklusif agar koneksi tetap berlanjut.

Stapling memperbaiki cara bukti dikirim, tetapi stapling opsional tidak otomatis membuat bukti itu wajib.

Sertifikat dapat mengikat penerimaan pada fitur TLS

RFC 7633 mendefinisikan ekstensi X.509 TLS Feature. Ekstensi ini membawa identifier fitur TLS yang diharapkan diterima client ketika menggunakan sertifikat tersebut. Karena berada di dalam sertifikat, ekstensi ini tercakup oleh signature CA penerbit.

Untuk kasus OCSP, nilai fitur yang sesuai dengan status_request menyatakan bahwa sertifikat dimaksudkan untuk digunakan hanya ketika perilaku status sertifikat yang diwajibkan tersedia. Konstruksi ini umum disebut OCSP Must-Staple.

Efek keamanannya berasal dari pemindahan requirement dari perilaku koneksi yang tidak terautentikasi ke metadata sertifikat yang bertanda tangan. Intermediary masih dapat menjatuhkan paket atau mengganggu handshake, tetapi tidak dapat menghapus ekstensi dari sertifikat tanpa merusak signature sertifikat.

Ekstensi ini tidak membuat respons OCSP otomatis tepercaya hanya karena dikirim lewat TLS. Respons tetap memiliki requirement validasinya sendiri. Must-Staple mengubah konsekuensi dari bukti yang hilang; ia tidak menggantikan verifikasi respons OCSP.

Hard failure memindahkan tanggung jawab ke operator server

Sertifikat yang membawa nilai TLS Feature yang relevan menciptakan kewajiban operasional pada setiap endpoint yang dapat menyajikannya. Setiap titik terminasi TLS membutuhkan akses ke material OCSP yang dapat diterima dan harus mengirimkannya dalam bentuk protokol yang diharapkan client yang patuh.

Requirement ini bersinggungan langsung dengan arsitektur deployment sertifikat. Satu sertifikat dapat dipasang di load balancer, reverse proxy, edge node, atau failover site. Jika satu endpoint tidak memiliki state stapling yang masih valid, traffic yang diarahkan ke sana dapat gagal meskipun endpoint lain sehat.

Freshness status juga menciptakan siklus refresh yang terpisah dari renewal sertifikat. Sertifikat dapat valid berbulan-bulan, sedangkan respons OCSP memiliki interval penggunaan yang jauh lebih pendek. Menyajikan respons cache yang sama tanpa batas bukan strategi yang valid; respons harus tetap diterima oleh aturan validasi status client.

Deployment yang tangguh karena itu memperlakukan pengambilan dan refresh respons OCSP sebagai bagian dari state penyajian TLS. Monitoring yang hanya memeriksa masa berlaku sertifikat akan melewatkan failure mode terpisah yang timbul dari dependency status yang keras ini.

Staple yang basi tidak sama dengan staple yang hilang

Requirement tidak terpenuhi hanya dengan menaruh sembarang byte di field status sertifikat. Client yang menerima respons OCSP tetap harus memvalidasinya.

Respons dapat gagal karena beberapa alasan. Respons mungkin merujuk sertifikat yang salah, memiliki signature tidak valid, menyatakan sertifikat sudah direvoke, atau berada di luar batas waktu yang diterima client. Respons seperti itu tidak dapat dianggap bukti hanya karena server secara teknis mengirim sebuah staple.

Perbedaan ini penting dalam analisis kegagalan. Server dapat terlihat sudah dikonfigurasi untuk stapling tetapi tetap menghasilkan koneksi yang ditolak client. Pemeriksaan operasional perlu mengevaluasi validitas semantik dari respons yang dikirim, bukan sekadar keberadaan ekstensi TLS.

Perilaku clock juga menjadi bagian dari batas. Respons OCSP memiliki field waktu dan client menerapkan kebijakan terhadap nilai tersebut. Kesalahan waktu besar pada titik validasi dapat memengaruhi penerimaan meskipun respons cache diperoleh secara normal.

Ketersediaan status revokasi menjadi bagian dari ketersediaan layanan

Must-Staple sengaja menghubungkan infrastruktur status sertifikat dengan keberhasilan koneksi. Hubungan ini menutup ambiguitas soft-fail, tetapi juga membuka permukaan denial-of-service ketika status valid tidak dapat diperbarui.

Outage pada OCSP responder dapat berubah menjadi outage layanan di kemudian hari ketika respons cache berhenti memenuhi kebijakan client. Network partition antara edge TLS dan responder dapat menghasilkan efek yang sama. Server mungkin masih memiliki private key, certificate chain, data aplikasi, dan konektivitas jaringan, tetapi koneksi TLS baru tetap gagal karena bukti status yang diwajibkan sudah tidak dapat diterima.

Caching mengurangi ketergantungan langsung pada reachability responder. Namun dependency tidak hilang; bentuknya berubah dari akses online per client menjadi refresh berkala di sisi server.

Trade-off ini eksplisit: deployment dapat memilih koneksi gagal daripada menerima sertifikat ketika bukti revokasi yang diwajibkan tidak tersedia. Itu adalah kebijakan keamanan, bukan kecelakaan protokol.

Must-Staple tidak memperbaiki semua kelemahan revokasi

Mekanisme ini tidak dapat membuat OCSP responder yang sudah dikompromikan menjadi jujur, memperbaiki respons good yang salah diterbitkan, atau memaksa CA menyediakan status dengan kualitas operasional tertentu. Jaminannya tetap dibatasi oleh aktor PKI dan aturan validasi yang menghasilkan serta mengautentikasi data OCSP.

Must-Staple juga tidak merevoke sertifikat secara retroaktif. State revokasi tetap berasal dari sistem status sertifikat. Ekstensi TLS Feature hanya menetapkan requirement pengiriman untuk perilaku TLS tertentu.

Dukungan client adalah batas lain. Properti hard-fail yang dimaksud bergantung pada relying-party software yang benar-benar menerapkan ekstensi sertifikat sesuai spesifikasi. Sistem yang mengabaikan nilai TLS Feature tidak memperoleh enforcement hanya karena sertifikat memuatnya.

TLS 1.3 juga mengubah lokasi status stapled di wire dibanding TLS 1.2. Implementasi harus mengikuti perilaku yang benar untuk versi protokol, bukan mengasumsikan pesan mandiri CertificateStatus selalu ada.

Sertifikat mengubah penghilangan menjadi pelanggaran kebijakan yang dapat diverifikasi

OCSP stapling opsional mengoptimalkan pengiriman status sambil tetap kompatibel dengan server yang tidak menyediakan staple. Must-Staple mengubah kontrak penerimaan: sertifikat menyatakan bahwa perilaku fitur TLS tertentu wajib tersedia.

Perubahan encoding-nya kecil, tetapi dampak operasionalnya besar. Status yang hilang atau tidak dapat diterima tidak lagi berada di luar syarat penggunaan sertifikat. Kondisi tersebut menjadi alasan bagi client yang patuh untuk menolak koneksi.

Mekanisme ini karena itu menukar graceful degradation dengan enforcement status revokasi yang lebih kuat. Nilainya bergantung pada apakah trade-off tersebut memang disengaja: refresh status, konsistensi edge, outage responder, umur cache, dan enforcement client semuanya menjadi bagian dari batas layanan sertifikat yang sebenarnya.