OCSP Stapling Memindahkan Bukti Pencabutan ke TLS Handshake

Sertifikat TLS dapat masih berada dalam masa berlaku setelah penerbitnya menandai sertifikat tersebut sebagai dicabut. Tanggal dan tanda tangan pada sertifikat tidak memuat perubahan status yang terjadi kemudian, sehingga client yang menerapkan pemeriksaan pencabutan memerlukan informasi status dari mekanisme lain. OCSP menyediakan respons status bertanda tangan untuk sertifikat tertentu. OCSP stapling mengubah jalur pengirimannya: TLS server mengambil respons lalu mengirim bukti bertanda tangan itu kepada client selama handshake.

Perbedaannya terletak pada arsitektur. Server mengangkut bukti, tetapi tidak menjadi otoritas yang menandatangani status sertifikat. Client tetap memvalidasi respons OCSP berdasarkan aturan PKI yang relevan dan kebijakannya sendiri. Stapling dengan demikian memisahkan distribusi status dari otoritas status.

Query OCSP langsung menambah dependensi jaringan

Dalam model dasar OCSP pada RFC 6960, client mengirim request ke OCSP responder dan menerima respons bertanda tangan yang menyatakan status sebuah sertifikat. Desain ini dapat menyediakan status tanpa mengunduh certificate revocation list secara lengkap, tetapi menambahkan interaksi jaringan lain ke proses validasi sertifikat.

Request tambahan membawa konsekuensi operasional. Koneksi TLS dapat bergantung pada keterjangkauan responder eksternal, dan query langsung dapat mengungkap kepada responder bahwa sebuah client sedang memeriksa sertifikat tertentu. Caching dapat mengurangi volume request, tetapi tidak menghapus dependensi tersebut dari arsitektur.

OCSP stapling memindahkan proses pengambilan ke sisi server. Server secara berkala mengambil respons OCSP bertanda tangan dan dapat memakai ulang respons itu pada banyak TLS handshake selama masih dapat diterima oleh kebijakan validasi yang berlaku. Client menerima objek status yang didukung tanda tangan pihak penerbit tanpa membuat request sendiri ke responder untuk handshake tersebut.

Perubahan ini tidak menjadikan respons sebagai pernyataan server. Respons OCSP tetap merupakan objek yang ditandatangani secara terpisah. Endpoint TLS yang disusupi atau salah konfigurasi tidak dapat membuat respons good yang sah atas otoritas penerbit hanya dengan menaruh byte sembarang di dalam handshake.

status_request menegosiasikan pengiriman

RFC 6066 mendefinisikan ekstensi TLS Certificate Status Request yang umum dikaitkan dengan OCSP stapling. Client dapat menyertakan status_request di ClientHello untuk menyatakan permintaan informasi status sertifikat. Pada TLS 1.2 dan versi sebelumnya, server yang berpartisipasi membawa respons OCSP dalam pesan handshake CertificateStatus.

TLS 1.3 mengubah lokasi data tersebut tanpa mengubah peran keamanan dasarnya. RFC 8446 menetapkan bahwa informasi OCSP dari server dibawa dalam ekstensi status_request pada CertificateEntry yang terkait dengan sertifikat. Objek status tetap ditafsirkan menurut aturan OCSP.

Perbedaan versi itu relevan bagi implementasi protokol dan analisis paket, tetapi tidak mengubah trust boundary. Dalam kedua kasus, peer TLS menyampaikan bukti status yang otoritasnya berasal dari tanda tangan OCSP dan validasi PKI, bukan dari peer yang mengangkutnya.

Negosiasi tersebut juga bukan kewajiban universal bagi setiap server untuk menyediakan staple. Pada mekanisme stapling dasar, dukungan dan pengiriman respons bergantung pada versi protokol, perilaku endpoint, request client, dan kebijakan lokal. Menganggap ketiadaan staple sebagai bukti pencabutan akan menambahkan aturan yang tidak diberikan oleh mekanisme dasar.

Respons yang di-staple memiliki jendela validitas

Stapling dapat dipakai secara operasional karena respons OCSP bertanda tangan tidak terikat pada satu koneksi client. Server dapat menyimpan respons yang masih dapat diterima lalu menyajikannya berulang kali. Sifat ini sekaligus membuat freshness perlu ditangani secara eksplisit.

Respons OCSP memuat status dan field waktu yang didefinisikan RFC 6960. Kebijakan validasi dapat mempertimbangkan nilai seperti thisUpdate, nextUpdate bila tersedia, serta waktu produksi respons. Aturan penerimaan yang tepat berada pada client atau profil aplikasi; server tidak dapat membuat respons lama menjadi baru hanya dengan men-staple ulang.

Kondisi tersebut menciptakan kewajiban pemeliharaan pada endpoint TLS. Endpoint atau infrastruktur di sekitarnya perlu memperbarui material status sebelum respons yang dipasang keluar dari jendela penerimaan client. Pembaruan dan rotasi sertifikat juga perlu dikoordinasikan karena respons OCSP mengidentifikasi status sertifikat; material status untuk sertifikat lama bukan pengganti material status yang mencakup sertifikat baru.

Deployment karena itu dapat gagal walaupun private key dan certificate chain telah dikonfigurasi dengan benar. Jika kebijakan mensyaratkan status staple yang dapat dipakai, material OCSP yang kedaluwarsa atau hilang menjadi bagian dari ketersediaan koneksi.

Stapling mengubah batas privasi dan ketersediaan

OCSP langsung menempatkan client, responder, dan endpoint TLS dalam jalur online tiga pihak. Stapling mengubah topologi itu. TLS server menghubungi infrastruktur status, lalu mendistribusikan hasil bertanda tangan kepada client.

Pergeseran ini memberi manfaat privasi: client tidak memerlukan query terpisah ke responder untuk status sertifikat yang di-staple. Jumlah client yang bergantung langsung pada ketersediaan responder saat koneksi juga berkurang. Gangguan responder tetap dapat berdampak karena server pada akhirnya membutuhkan status baru, tetapi respons yang di-cache dapat memisahkan handshake individual dari round trip langsung ke responder selama respons itu masih dapat diterima.

Konsekuensinya, refresh status menjadi bagian dari infrastruktur server. Operator memerlukan penanganan kegagalan yang membedakan masalah responder sementara dari respons yang benar-benar telah melewati masa penerimaan sesuai kebijakan deployment. Menyajikan status cache tanpa batas merusak sifat freshness; memutus seluruh traffic pada kegagalan refresh pertama dapat menciptakan kegagalan ketersediaan lain.

Tidak ada satu interval retry atau umur cache yang ditentukan oleh stapling saja. Nilainya bergantung pada timing respons, perilaku certificate authority, enforcement client, dan kebijakan operasional.

Must-Staple menjadikan ketiadaan status sebagai kondisi sertifikat

OCSP stapling dasar menyisakan ambiguitas penting: ketika client meminta staple tetapi tidak menerimanya, ketiadaan itu dapat berasal dari fitur yang tidak didukung, konfigurasi, atau penghilangan yang disengaja. RFC 7633 mendefinisikan ekstensi X.509v3 TLS Feature agar sertifikat dapat menyatakan fitur TLS yang diwajibkan. Penggunaannya bersama status_request umum disebut OCSP Must-Staple.

Bagi client yang mengenali dan menerapkan nilai TLS Feature terkait, sertifikat mengubah makna status yang hilang. RFC 7633 mewajibkan client tersebut memperlakukan sertifikat sebagai tidak valid ketika server tidak menawarkan fitur yang disyaratkan dalam kondisi yang ditetapkan standar.

Aturan ini lebih kuat daripada stapling biasa, tetapi juga memindahkan tekanan ketersediaan ke penyediaan status. Server yang menyajikan sertifikat dengan kewajiban stapling memerlukan material OCSP yang dapat diterima saat client terhubung. Karena itu RFC 7633 menyarankan server tidak mulai memakai sertifikat pengganti sebelum token status yang diperlukan tersedia.

Must-Staple tidak membuat pencabutan menjadi seketika. Mekanisme ini menjadikan pengiriman fitur status yang diwajibkan sebagai bagian dari validasi sertifikat bagi client yang mengimplementasikan dan menerapkan ekstensi tersebut. Freshness tetap bergantung pada respons OCSP bertanda tangan dan kebijakan validasi, sedangkan dukungan ekosistem tetap merupakan pertimbangan implementasi, bukan sifat yang dapat dipaksakan sertifikat kepada software yang tidak mengimplementasikan fitur itu.

Bukti pencabutan lebih sempit daripada kepercayaan endpoint

Status OCSP good memiliki arti khusus di dalam model OCSP dan PKI. Status itu bukan pernyataan bahwa endpoint bebas kompromi, perilaku aplikasinya aman, atau sertifikat diterbitkan dalam kondisi operasional ideal. Status tersebut juga tidak menggantikan pemeriksaan hostname, validasi certificate path, batasan key usage, atau persyaratan autentikasi TLS lainnya.

Pemisahan sebaliknya juga penting. Certificate chain yang valid secara kriptografis bukan bukti status pencabutan terkini. Konstruksi path, masa berlaku sertifikat, dan status pencabutan menjawab pertanyaan yang berbeda.

OCSP stapling paling tepat diperlakukan sebagai mekanisme transport untuk bukti pencabutan bertanda tangan. Nilai keamanannya berasal dari dipertahankannya objek status autentik milik responder sambil mengubah lokasi pengambilan objek tersebut. Biaya operasionalnya muncul karena pengambilan status tepat waktu menjadi bagian dari pemeliharaan layanan TLS, terutama ketika kebijakan sertifikat mewajibkan staple.

Batas enforcement berada pada client

Server dapat mengambil status, menyimpannya dalam cache, men-staple-nya, dan memantau kegagalan refresh. Tidak satu pun tindakan tersebut menetapkan apa yang harus diterima oleh setiap client. Keputusan enforcement akhir tetap berada pada client yang melakukan validasi dan kebijakan yang diterapkannya.

Batas ini mencegah beberapa klaim deployment yang menyesatkan. Mengaktifkan stapling pada server tidak membuktikan bahwa setiap client memeriksa respons. Menambahkan Must-Staple pada sertifikat tidak menambahkan dukungan fitur ke client yang tidak memilikinya. TLS handshake yang berhasil pada satu client tidak membuktikan bahwa client lain menerapkan kebijakan pencabutan yang sama.

Model operasional yang berguna karena itu bersifat eksplisit: CA dan OCSP responder menghasilkan bukti status; endpoint TLS mendistribusikannya; sertifikat dapat menyatakan fitur TLS yang diwajibkan; dan client menentukan apakah bukti yang disajikan memenuhi aturan validasinya. Pemisahan peran tersebut membuat kegagalan lebih mudah diklasifikasikan dan mencegah optimasi distribusi dianggap sebagai jaminan pencabutan universal.

Referensi

Keamanan Siber TLS PKI OCSP