OCSP Stapling Membawa Status Revocation di TLS

Validasi sertifikat menjawab lebih dari satu persoalan. Client dapat memeriksa signature, nama, masa berlaku, dan trust anchor, tetapi sertifikat yang lolos pemeriksaan tersebut masih dapat berstatus revoked setelah diterbitkan. Status revocation karena itu berada di samping validasi path normal, bukan menggantikannya.

Online Certificate Status Protocol (OCSP) menyediakan response status bertanda tangan untuk sertifikat. Client dapat melakukan query langsung ke OCSP responder, tetapi cara itu menambahkan pihak ketiga ke proses pembentukan koneksi. OCSP stapling memindahkan response yang sesuai ke pertukaran TLS: server mengambil response lalu menyajikannya kepada client yang meminta status sertifikat.

Server membawa status bertanda tangan dari issuer

OCSP stapling tidak memberi TLS server hak untuk menyatakan sertifikatnya sendiri valid. Objek status tetap berupa OCSP response yang autentisitas dan kecocokannya harus diperiksa client.

Alur dasarnya:

certificate issuer / OCSP responder
             |
             | signed OCSP response
             v
          TLS server
             |
             | certificate + stapled status
             v
           client

RFC 6066 mendefinisikan extension TLS status_request. Client dapat menyatakan bahwa ia menginginkan informasi status sertifikat. Dalam struktur protokol TLS 1.2 dan versi sebelumnya, server yang berpartisipasi dapat mengirim OCSP response melalui handshake message CertificateStatus.

TLS 1.3 tetap memakai status_request, tetapi lokasi response berubah. Server menempatkan status sertifikat pada extension yang terkait dengan entry Certificate yang bersangkutan. Kode parser untuk handshake TLS 1.2 tidak dapat begitu saja mengasumsikan posisi wire yang sama pada TLS 1.3.

Stapling menghapus perjalanan responder per client

Tanpa stapling, pemeriksaan OCSP langsung dapat mengharuskan client menghubungi responder milik issuer ketika membentuk kepercayaan pada sertifikat server. Dependensi ini memiliki dampak operasional: request jaringan tambahan dapat menambah latency, keterjangkauan responder dapat memengaruhi pengambilan status, dan responder dapat melihat query status sertifikat.

Dengan stapling, server dapat memperbarui OCSP response sesuai jadwalnya sendiri dan memakai kembali response yang masih valid untuk banyak koneksi client. Client menerima objek status melalui koneksi TLS tanpa membuat OCSP request terpisah untuk koneksi tersebut.

Perubahan ini menyangkut transport, bukan otoritas. Server bertindak sebagai kurir untuk data status bertanda tangan. Server tidak memperoleh kemampuan membuat response issuer yang valid hanya dengan memasukkan byte ke TLS.

Stapled response tetap harus divalidasi

Menerima OCSP response belum cukup. Client harus menerapkan aturan OCSP dan validasi sertifikat yang relevan dengan policy-nya. Response antara lain harus merujuk ke sertifikat yang sedang diperiksa, membawa status yang dapat diterima, diautentikasi oleh responder yang berwenang, serta memenuhi batas waktu yang berlaku.

Model operasional ringkasnya:

stapled bytes
    |
    +--> parse response
    +--> authenticate response
    +--> match certificate
    +--> check status
    +--> check response timing
    |
    v
client policy decision

Response yang stale, malformed, tidak terkait, atau tidak terautentikasi tidak setara dengan response good yang masih berlaku. Implementasi juga perlu membedakan status OCSP good dari klaim umum bahwa seluruh aspek sertifikat aman. Status OCSP tidak menggantikan pemeriksaan hostname, path construction, verifikasi signature, policy processing, atau pemeriksaan sertifikat TLS lainnya.

Status yang hilang biasanya bersifat ambigu

Mekanisme stapling awal bersifat opsional. RFC 6066 mengizinkan server tidak mengirim message CertificateStatus meskipun menerima status_request. Karena itu, client secara umum tidak dapat memperlakukan ketiadaan staple sebagai bukti bahwa sertifikat berstatus revoked.

Ambiguitas ini penting saat ada serangan aktif. Jika client menerima koneksi ketika status tidak tersedia, penyerang yang dapat menekan pengiriman status opsional dapat memperoleh hasil yang sama dengan server yang memang tidak melakukan stapling.

RFC 7633 mendefinisikan X.509 TLS Feature extension untuk menyatakan bahwa sebuah sertifikat mengharapkan fitur TLS tertentu. Fitur yang umum dikaitkan dengan OCSP Must-Staple adalah status_request. Ketika policy client mendukung dan menegakkan fitur sertifikat tersebut, status wajib yang tidak tersedia dapat menjadi kegagalan koneksi, bukan sekadar ketiadaan yang ambigu.

Must-Staple dengan demikian mengubah semantik kegagalan, bukan sumber kriptografis data revocation. Fitur ini juga menimbulkan kewajiban availability: server yang menyajikan sertifikat tersebut perlu memiliki bukti status yang dapat dipakai ketika client mewajibkannya.

Waktu refresh menjadi bagian dari keamanan deployment

Server tidak dapat menyimpan satu OCSP response selamanya. OCSP response memiliki informasi waktu yang membatasi masa gunanya, sedangkan policy client menentukan apakah response masih dapat diterima.

Deployment sebaiknya memperbarui staple sebelum response saat ini tidak lagi dapat digunakan dan tidak mengganti cached response yang valid dengan hasil fetch yang invalid. Margin refresh yang tepat merupakan pilihan operasional yang dibatasi timing response dan perilaku client.

State machine praktis dapat tetap sederhana:

fetch new response
       |
       v
validate for target certificate
       |
   +---+---+
   |       |
 valid   invalid
   |       |
cache     keep prior usable response
   |
serve while acceptable

Pola ini tidak menjamin layanan tanpa putus. Gangguan responder yang berlangsung melewati masa guna response tetap dapat membuat server tidak memiliki bukti yang dapat diterima, terutama bagi sertifikat dengan policy yang mewajibkan stapling.

Cakupan chain bergantung pada versi protokol dan mekanisme

Bentuk RFC 6066 membawa satu OCSP response dan dirancang di sekitar sertifikat server. RFC 6961 kemudian mendefinisikan status_request_v2 untuk mendukung beberapa response status sertifikat, termasuk status sertifikat intermediate.

TLS 1.3 mendeprekasi status_request_v2; server TLS 1.3 tidak boleh bertindak berdasarkan extension tersebut. TLS 1.3 sebagai gantinya memungkinkan informasi status status_request dikaitkan dengan entry sertifikat individual. Implementasi harus mengikuti aturan versi TLS yang dinegosiasikan, bukan memperlakukan extension multiple-status lama sebagai mekanisme portabel untuk semua versi.

Perbedaan ini mudah tersembunyi di balik antarmuka konfigurasi yang hanya menampilkan satu switch “OCSP stapling”. Label yang sama dapat menutupi encoding protokol dan cakupan chain yang berbeda secara material.

Stapling melengkapi komponen PKI lainnya

OCSP stapling adalah optimasi delivery yang membawa konsekuensi keamanan, bukan sistem revocation lengkap. Issuer tetap menghasilkan informasi status. Server tetap memerlukan certificate chain yang valid dan proses untuk memperbarui status. Client tetap menentukan apakah bukti yang diberikan dapat diterima.

Kontrol ini berada dalam lifecycle sertifikat yang lebih luas:

issuance -> deployment -> status publication -> stapling -> client validation

Kegagalan pada tahap berbeda memerlukan respons berbeda. Kredensial penerbitan yang bocor memerlukan containment dan penggantian sertifikat. Konfigurasi server yang keliru memerlukan perbaikan deployment. Stapled status yang kedaluwarsa atau invalid memerlukan refresh dan pemeriksaan jalur responder. Stapling membuat bukti revocation tersedia di dalam TLS, tetapi nilainya bergantung pada response issuer yang benar, perilaku refresh server, dan enforcement client.