OCSP Stapling Membawa Status Sertifikat ke dalam TLS Handshake

Certificate chain yang valid menjawab satu pertanyaan penting dalam TLS: apakah public key yang disajikan dapat ditautkan melalui issuer tepercaya ke identitas yang diminta? Chain tersebut tidak dengan sendirinya menyatakan bahwa sertifikat yang belum kedaluwarsa masih dapat diterima oleh issuer.

Mekanisme revocation menangani status yang terpisah itu. Online Certificate Status Protocol (OCSP) memungkinkan relying party meminta status sertifikat dari OCSP responder. OCSP stapling mengubah pihak yang membawa status tersebut. Alih-alih mengharuskan setiap client menghubungi responder saat koneksi dibuat, server TLS dapat mengambil respons OCSP bertanda tangan dan menyertakannya ke handshake.

Server tidak membuat pernyataan status itu. Server membawa respons yang keaslian dan freshness-nya dapat dievaluasi client berdasarkan aturan PKI.

Query OCSP langsung menambah dependensi saat koneksi dibuat

Tanpa stapling, client yang menjalankan pemeriksaan OCSP mungkin memerlukan jalur jaringan menuju responder yang ditentukan issuer. Kondisi ini menambah dependensi di luar koneksi antara client dan application server.

Alurnya dapat disederhanakan seperti berikut:

client ----------------------> TLS server
  |
  +---- OCSP request --------> OCSP responder
  <---- signed response ------+

Susunan ini memiliki konsekuensi operasional dan privasi. Responder menerima query status sertifikat dari client, sementara availability atau latency responder dapat memengaruhi client yang kebijakannya mensyaratkan jawaban tepat waktu.

Perilaku client tidak seragam. Kegagalan lookup OCSP dapat diperlakukan sebagai hard failure, soft failure, atau bahkan tidak dicoba pada validation path tertentu. Karena itu, OCSP bukan jaminan universal bahwa setiap client akan menolak setiap sertifikat yang telah dicabut.

Stapling mengubah pengiriman, bukan otoritas

Dengan OCSP stapling, server secara berkala mengambil respons dari OCSP responder yang sesuai lalu menyajikannya selama negosiasi TLS:

             periodic fetch
TLS server --------------------> OCSP responder
           <-------------------- signed status

client ------------------------> TLS server
       certificate + OCSP response

Respons status ditandatangani secara kriptografis sesuai aturan OCSP. Client dapat memverifikasi respons tersebut tanpa harus mempercayai pernyataan server TLS tentang sertifikatnya sendiri.

Pemisahan ini penting. Application server yang disusupi atau salah konfigurasi tidak dapat secara sah mengubah respons revoked bertanda tangan issuer menjadi good hanya dengan menempelkan data pilihannya. Server dapat tidak menyertakan staple kecuali ada kebijakan lain yang mewajibkannya, dan server hanya dapat menyajikan respons yang bersedia diterima client setelah validasi.

Freshness menjadi bagian dari validasi status

Respons OCSP merepresentasikan status sertifikat untuk periode terbatas, bukan selamanya. Field seperti thisUpdate dan, jika tersedia, nextUpdate membantu client menentukan apakah respons masih cukup baru menurut kebijakannya.

Artinya, server tidak dapat mengambil satu respons good lalu menggunakannya dengan aman tanpa batas waktu. Staple harus diperbarui sebelum tidak lagi dapat diterima client.

Refresh loop yang praktis perlu menangani beberapa keadaan:

fetch response
     |
     v
validate response
     |
     +---- unusable ----> keep serving only if policy permits
     |
     +---- usable ------> cache
                            |
                            v
                     staple to handshakes
                            |
                            v
                     refresh before expiry

Waktu refresh sebaiknya menyediakan ruang untuk kegagalan responder yang bersifat sementara. Menunggu hingga saat terakhir dapat mengubah gangguan upstream singkat menjadi risiko penyajian staple yang kedaluwarsa.

Server juga perlu mengganti status dalam cache ketika sertifikat berubah. Respons OCSP mengidentifikasi sertifikat tertentu melalui certificate identifier milik OCSP; respons untuk sertifikat lama bukan bukti status bagi sertifikat penggantinya.

Stapling mengurangi eksposur client ke responder

Request OCSP langsung dapat mengungkap kepada responder bahwa sebuah client sedang memeriksa sertifikat yang terkait dengan suatu site. Stapling memindahkan pengambilan rutin ke server, sehingga client dapat menerima material status tanpa membuat query terpisah untuk sertifikat yang di-staple.

Ini merupakan perbaikan privasi dengan ruang lingkup yang spesifik. TLS tetap mengekspos atau melindungi metadata yang berbeda bergantung pada versi protokol, extension, perilaku DNS, dan deployment. OCSP stapling menangani jalur lookup status sertifikat; mekanisme ini bukan perlindungan privasi browsing secara umum.

Stapling juga mengurangi traffic berulang ke responder. Satu respons di sisi server dapat digunakan kembali untuk banyak handshake selama masih valid, sesuai kebijakan client.

Staple tetap memerlukan validasi penuh

Menerima sekumpulan byte yang diberi label sebagai respons OCSP belum cukup. Validation path di sisi client harus memastikan bahwa respons berlaku untuk sertifikat terkait, ditandatangani oleh responder yang berwenang, membawa status yang dapat diterima, dan memenuhi batas freshness.

Secara konseptual:

stapled response
      |
      +-- matches certificate? ------ no --> reject status evidence
      |
      +-- authorized signature? ----- no --> reject status evidence
      |
      +-- current enough? ----------- no --> reject status evidence
      |
      +-- acceptable status? -------- no --> apply revocation policy
      |
      +-- yes ----------------------------> usable status evidence

Konsekuensi tepat dari status yang hilang, malformed, stale, atau indeterminate bergantung pada protokol dan kebijakan validasi client. Menganggap semua kegagalan setara dapat menghasilkan outage yang tidak perlu atau justru menghilangkan pemeriksaan revocation yang dimaksud tanpa terlihat.

Must-Staple membuat ketiadaan staple signifikan bagi client pendukung

TLS Feature certificate extension yang didefinisikan dalam RFC 7633 dapat menunjukkan bahwa sertifikat mengharapkan TLS feature tertentu. Penggunaan yang umum dibahas adalah feature status_request yang terkait dengan OCSP stapling, sering disebut OCSP Must-Staple.

Bagi client yang mengimplementasikan dan menegakkan extension tersebut, staple yang dapat diterima menjadi bagian dari pemrosesan sertifikat yang berhasil. Ketiadaan staple berubah dari kegagalan optimasi opsional menjadi kondisi yang dapat menggagalkan koneksi.

Perilaku yang lebih ketat itu juga meningkatkan tuntutan operasional pada server. Certificate deployment, OCSP refresh, cache persistence, load balancer, TLS termination point, dan failover path harus mempertahankan staple yang dapat digunakan. Mengaktifkan persyaratan tersebut tanpa mekanisme refresh dan distribusi yang andal dapat mengubah masalah responder atau deployment menjadi outage aplikasi.

Dukungan dan enforcement berbeda antar-TLS client. Deployment tidak boleh mengasumsikan bahwa extension tersebut menghasilkan perilaku identik pada seluruh populasi client.

TLS termination menentukan lokasi stapling

Pada banyak sistem, application process bukan komponen yang mengakhiri TLS. Reverse proxy, CDN, ingress controller, atau load balancer yang menyajikan sertifikat.

Komponen yang menjalankan TLS handshake harus memiliki sertifikat, akses ke private key sesuai kebutuhan deployment, serta stapling state terkait. Mengambil respons OCSP di dalam aplikasi yang berada di belakang terminator tidak membuat respons itu muncul pada TLS handshake eksternal.

Hal ini penting saat failover. Jika dua terminator melayani sertifikat yang sama, keduanya memerlukan cara yang valid untuk mengambil atau menerima status terbaru. Standby yang memiliki key dan sertifikat tetapi tidak memiliki stapling state terbaru dapat berperilaku berbeda saat mulai menerima traffic.

Monitoring perlu memeriksa artefak status, bukan hanya HTTPS reachability

Probe HTTPS dasar dapat berhasil saat staple tidak tersedia, bergantung pada konfigurasi sertifikat dan kebijakan client. Pemeriksaan operasional untuk stapling perlu menginspeksi perilaku status sertifikat itu sendiri.

Sinyal yang berguna mencakup keberadaan staple ketika diharapkan, keberhasilan validasi OCSP signature, certificate identifier yang dicakup, status yang dilaporkan, serta freshness window. Alert sebelum periode penggunaan berakhir memberi refresh path waktu untuk pulih.

Monitoring juga perlu membedakan masalah pada OCSP responder dari masalah caching atau konfigurasi TLS lokal. Keduanya dapat menghasilkan staple yang hilang atau stale, tetapi tindakan perbaikannya berbeda.

Stapling adalah optimasi transport dengan konsekuensi keamanan

OCSP stapling menghilangkan fetch rutin di sisi client dengan membawa status bertanda tangan issuer di dalam TLS handshake. Mekanisme ini dapat mengurangi eksposur privasi ke OCSP responder, menekan beban responder, dan menghindari network request terpisah langsung pada jalur koneksi client.

Nilai keamanannya bergantung pada detail validasi dan lifecycle. Respons harus mencakup sertifikat yang tepat, berasal dari signer yang berwenang, tetap cukup baru, dan mencapai setiap TLS termination point yang membutuhkannya. Kebijakan client tetap menentukan tindakan ketika status tidak tersedia atau tidak dapat digunakan.

Prinsip desainnya spesifik: perlakukan stapled OCSP response sebagai bukti status sertifikat yang bertanda tangan dan berbatas waktu, bukan sebagai properti permanen sertifikat serta bukan sebagai pernyataan yang dibuat server.

References

Cybersecurity TLS PKI OCSP