OCSP Stapling Membawa Status Sertifikat dalam TLS Handshake

Validasi sertifikat mencakup dua persoalan yang berbeda. Client perlu memastikan bahwa sertifikat membentuk chain ke authority yang dipercaya dan valid untuk identitas yang dituju, tetapi client juga dapat memerlukan bukti terkini bahwa sertifikat belum dicabut sebelum masa berlakunya berakhir.

Online Certificate Status Protocol, atau OCSP, menyediakan response status bertanda tangan untuk sertifikat. Client dapat menghubungi OCSP responder secara langsung, tetapi langkah itu menambah dependency jaringan saat koneksi dibentuk dan dapat mengungkap sertifikat yang sedang diperiksa kepada responder. OCSP stapling memindahkan response yang sudah di-cache ke pertukaran TLS: server mengambil bukti status lalu menyajikannya kepada client yang memintanya.

Server tidak membuat pernyataan status tersebut. Server hanya membawa OCSP response yang autentisitas dan validitasnya tetap harus diperiksa oleh client.

Response status dikirim bersama sertifikat

Pada versi TLS yang memakai extension status_request dari RFC 6066, client dapat menyatakan bahwa ia menerima informasi status sertifikat selama handshake. Server yang mendukung mekanisme ini dapat mengirim OCSP response yang terkait dengan sertifikatnya.

Secara konseptual, pertukarannya seperti ini:

client
  |
  | ClientHello + status_request
  v
server
  |
  | certificate
  | stapled OCSP response
  v
client
  |
  | validasi chain
  | validasi OCSP response
  v
keputusan koneksi

Object yang di-staple adalah OCSP response lengkap yang di-encode sesuai protokol. Isinya bukan boolean buatan server seperti revoked=false. Client mengevaluasi response bertanda tangan tersebut berdasarkan policy validasi sertifikatnya.

TLS 1.3 membawa informasi status sertifikat sebagai extension yang terkait dengan certificate entry, bukan melalui handshake message CertificateStatus terpisah seperti pada TLS 1.2. Letaknya berubah, tetapi model utamanya tetap sama: bukti status dapat tiba secara in-band bersama proses autentikasi sertifikat.

Stapling menghapus lookup jaringan dari sisi client

Tanpa stapling, client yang melakukan live OCSP dapat memerlukan request terpisah ke infrastruktur yang dioperasikan oleh atau untuk certificate issuer. Request tambahan itu dapat menambah latency dan membuat pembentukan koneksi bergantung pada ketersediaan responder.

Stapling memindahkan proses pengambilan tersebut ke server. Server secara berkala mengambil OCSP response yang sesuai, menyimpannya di cache, lalu mengirim response yang sama pada banyak TLS handshake sampai interval statusnya mendekati akhir dan response perlu diganti.

Susunan ini memberi dua dampak praktis. Client dapat memvalidasi bukti yang diberikan tanpa membuat direct OCSP request yang sama untuk setiap koneksi, sedangkan OCSP responder dapat melayani infrastruktur situs alih-alih setiap pengunjung secara terpisah.

Privasi juga lebih baik dibanding direct OCSP lookup. Request langsung dapat mengungkap sertifikat yang sedang diperiksa client. Dengan stapling, client menerima object status dari server yang memang sedang dihubunginya.

Freshness menjadi bagian dari keputusan validasi

Caching bukan berarti menyimpan OCSP response tanpa batas. OCSP response membawa informasi waktu yang membatasi masa berlaku pernyataan status. Server harus memperbarui response di cache cukup awal agar bukti yang dikirim tetap dapat diterima client.

Secara operasional, deployment setidaknya perlu menangani tiga keadaan:

response masih fresh -> kirim response dari cache
refresh berjalan     -> tetap kirim cached response yang masih valid
response kedaluwarsa -> policy client menentukan perilaku kegagalan

Jadwal refresh yang tepat merupakan pilihan implementasi dan operasional. Jadwal tersebut sebaiknya menyediakan margin untuk outage responder dan percobaan ulang, bukan menunggu sampai response yang aktif hampir kedaluwarsa.

Ketepatan clock penting di kedua sisi. Client dengan clock yang melenceng jauh dapat menolak bukti yang sebenarnya valid atau menerima bukti di luar interval yang dimaksud, bergantung pada aturan validasinya.

Stapled response tetap memerlukan validasi kriptografis

Membawa OCSP response di dalam TLS tidak membuat response itu otomatis tepercaya hanya karena lokasinya. Client tetap perlu memvalidasi OCSP response sesuai aturan PKI yang berlaku, termasuk authorization responder, signature, identitas sertifikat yang dicakup response, nilai status, serta batas waktu yang relevan.

Response untuk sertifikat lain tidak dapat menggantikan response yang benar hanya karena dikirim oleh TLS server yang diharapkan. Demikian pula, signed response lama tidak menjadi terkini hanya karena server mengirimkannya kembali sebagai staple.

Pemisahan ini penting saat meninjau implementasi. Layer TLS membawa bukti; pemrosesan status sertifikat menentukan apakah bukti tersebut dapat diterima.

Status OCSP good juga memiliki arti yang terbatas. Status itu melaporkan keadaan sertifikat menurut informasi responder dan semantik OCSP. Status tersebut tidak menyatakan bahwa endpoint bebas kompromi, private key tidak pernah bocor, atau aplikasi aman.

Stapling biasa tidak memaksa setiap server mengirim staple

Request OCSP stapling dari client tidak dengan sendirinya menjamin server akan mengirim response. RFC 6066 mengizinkan server tidak mengirim message CertificateStatus meskipun telah menerima status request.

Perbedaan ini membatasi arti ketiadaan staple. Client secara umum tidak dapat menganggap staple yang hilang sebagai bukti pencabutan. Perilakunya bergantung pada certificate policy, application policy, versi protokol, serta mekanisme revocation checking yang diimplementasikan.

TLS Feature certificate extension dari RFC 7633 menyediakan mekanisme terpisah yang dapat mewajibkan fitur TLS tertentu. Penggunaan yang paling dikenal sering disebut OCSP Must-Staple: sertifikat dapat menyatakan bahwa client yang mendukung feature extension harus meminta stapled status response.

Must-Staple mengubah failure semantics sehingga operasi server menjadi lebih ketat. Jika sertifikat mewajibkan stapling dan server tidak dapat menyediakan bukti status yang dapat diterima, client yang mematuhi aturan tersebut dapat menolak koneksi alih-alih melanjutkan tanpa staple.

TLS 1.3 mempersempit rancangan multi-status lama

RFC 6961 mendefinisikan status_request_v2, termasuk mode untuk membawa informasi OCSP bagi beberapa sertifikat dalam sebuah chain. TLS 1.3 tidak menggunakan extension tersebut. RFC 8446 menetapkan bahwa server TLS 1.3 tidak bertindak berdasarkan status_request_v2.

Sebagai gantinya, TLS 1.3 memungkinkan informasi status dikaitkan dengan certificate entry melalui extension status_request pada struktur certificate message. Implementasi karena itu perlu membedakan perilaku tiap versi protokol dan tidak menganggap alur message TLS 1.2 berlaku tanpa perubahan.

Konfigurasi stapling juga perlu diuji memakai versi TLS dan client stack yang benar-benar digunakan di production. Munculnya staple pada satu mode handshake belum membuktikan bahwa setiap jalur protokol yang aktif membawa dan memvalidasinya sesuai rancangan.

Monitoring server perlu mencakup seluruh pipeline status

Deployment dapat memiliki sertifikat yang valid tetapi tetap gagal menyediakan stapled evidence yang dapat dipakai. Batas operasionalnya mencakup pengambilan response, parsing, caching, rotasi sebelum expiry, pemilihan response untuk sertifikat aktif, serta pemasangannya pada TLS handshake yang tepat.

Monitoring sebaiknya memeriksa status artifact itu sendiri, bukan hanya tanggal kedaluwarsa sertifikat. Pemeriksaan yang berguna mencakup keberadaan staple pada endpoint yang diharapkan, sertifikat yang dicakupnya, status yang dilaporkan, validity interval, serta sisa margin sebelum refresh diperlukan.

Rotasi sertifikat memerlukan perhatian khusus. Mengganti leaf certificate juga mengubah identitas sertifikat yang memerlukan bukti status. Cached response untuk sertifikat sebelumnya tidak memenuhi validasi sertifikat baru.

OCSP stapling adalah mekanisme pengiriman bukti revocation, bukan pengganti validasi sertifikat. Nilainya berasal dari pemindahan signed status object ke jalur TLS sambil mempertahankan issuer atau delegated responder sebagai authority untuk status tersebut. Deployment yang andal memperlakukan pengambilan response, freshness, rotasi sertifikat, dan pengiriman saat handshake sebagai satu rangkaian operasi certificate lifecycle.