OCSP berbanding CRL: cara setiap semakan pembatalan sebenarnya berfungsi

Salah satu daripada dua semakan pembatalan ini memulangkan jawapan bertandatangan tentang satu sijil, dan satu lagi memulangkan senarai bertandatangan yang anda muat turun sepenuhnya. Kedua-duanya bertujuan memberitahu pengesah sama ada sesuatu kelayakan masih dipercayai, dan kedua-duanya gagal dengan cara yang sama sekali tidak serupa. Urutan di bawah mengikut apa yang benar-benar ditemui pengendali dalam pengeluaran, bermula dengan bait pada wayar dan berakhir dengan gateway yang menolak sambungan. Melangkau satu langkah ialah cara sesuatu penggunaan berakhir dengan dasar pembatalan yang hanya wujud di atas kertas.

Langkah 1: Apa yang dipulangkan oleh setiap semakan dan berapa lama ia kekal boleh digunakan

CRL diterbitkan sebagai satu objek bertandatangan yang meliputi setiap sijil yang telah dibatalkan oleh pengeluar, jadi pengesah mengambilnya sekali dan menggunakannya semula sehingga nextUpdate senarai itu berlalu. Respons OCSP lebih sempit: ia menjawab tepat untuk satu sijil dan membawa thisUpdate, producedAt dan biasanya nextUpdate juga. Perbezaan itulah yang mengemudi segala-galanya. CRL yang dicache menjadi lapuk secara senyap, kerana fail itu masih dihuraikan dan tandatangannya masih disahkan, manakala respons OCSP yang luput jelas tidak bernilai pada saat anda membaca cap masanya.

Oleh itu cache ialah perkara pertama yang perlu ditetapkan: komponen mana yang menyimpan salinan, dan had atas apa yang dipatuhi salinan itu. Pada gateway had atasnya patut nextUpdate tolak margin keselamatan, tidak pernah apa yang dicadangkan secara kebetulan oleh pengepala cache HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate mencetak kedua-dua tarikh, dan senarai yang nextUpdate-nya sudah berada di masa lalu mesti dianggap hilang dan bukan sekadar lama.

Langkah 2: Ke mana sijil mengarahkan klien

Sijil daun biasanya membawa dua petunjuk: sambungan titik pengedaran CRL dan entri akses maklumat pihak berkuasa untuk OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints mencetak yang pertama, dan yang kedua terletak di bawah bahagian AIA openssl x509 -in client.pem -noout -text. Mana-mana sambungan ialah penunjuk, bukan kewajipan. Klien yang tidak pernah melaksanakan semakan pembatalan akan berhubung dengan sangat baik dengan sijil yang sambungannya menamakan responden yang sudah mati selama setahun.

Titik pengedaran sering menamakan hos dalaman yang hanya diselesaikan dalam satu segmen rangkaian, dan sesetengah klien lama menolak URL ldap secara langsung. Uji kebolehsampaian dari hos yang menamatkan terowong, bukan dari komputer riba anda sendiri, kerana itulah satu-satunya sudut pandangan yang kegagalannya benar-benar penting.

Langkah 3: Pilih fail-closed atau fail-open sebelum gangguan

Responden yang tidak dapat dicapai atau senarai yang luput memaksa keputusan: tolak sambungan, atau terima dan catat jurang itu. Subperintah verify OpenSSL menjadikan pilihan ketat itu eksplisit, kerana menambah -crl_check mengubah CRL yang tidak tersedia menjadi unable to get certificate CRL dan pengesahan yang gagal. Kegagalan lembut dalam kebanyakan tindanan sama sekali bukan bendera, ia ialah ketiadaan semakan, dan itulah sebabnya ia dihantar secara tidak sengaja.

Untuk melihat tingkah laku yang benar-benar dimiliki klien, keluarkan responden dan sambung semula. Jika terowong masih naik, cari baris log yang mencatat semakan yang dilangkau, kemudian tanya sama ada sesiapa akan membaca baris itu semasa insiden. Vendor yang sama boleh berbeza mengikut protokol: klien IKEv2 dan klien OpenVPN pada mesin yang sama membaca tetapan konfigurasi yang tidak berkaitan.

Langkah 4: Buktikan semakan berjalan di tempat trafik diterima

Cari proses yang menamatkan atau memberi kuasa kepada sambungan, kemudian tanyakan baris konfigurasi yang mengaktifkan semakan pembatalan. Gateway yang mengesahkan rantaian tetapi tidak pernah bertanya tentang pembatalan melaksanakan dasar yang berbeza daripada yang ada dalam dokumentasi anda, dan tiada tangkapan skrin rantaian sijil membuktikan sebaliknya. OpenVPN menulis pilihan itu sebagai crl-verify; strongSwan menyimpan carian CRL dan OCSP di bawah konfigurasi CA, tempat crl_uris atau ocsp_uris ditetapkan. Jika anda tidak boleh menunjuk sama ada satu pun, anggap semakan itu tiada.

Respons OCSP hanya sah apabila CA pengeluar menandatanganinya, atau apabila responden yang memegang penggunaan kunci lanjutan OCSPSigning yang diwakilkan oleh CA itu menandatanganinya, jadi jawapan daripada perkhidmatan yang tidak berkaitan tidak membuktikan apa-apa. Jika anda mengendalikan responden itu sendiri, pantau ia sebagai kebergantungan keras, kerana satu perkhidmatan mati menjadi gangguan kepada setiap klien fail-closed sekali gus.

Langkah 5: Batalkan satu sijil dengan sengaja

Ambil sijil ujian, batalkan melalui saluran yang sama dengan yang digunakan oleh pengeluaran, dan tanya responden secara terus. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text sepatutnya melaporkan Cert Status: revoked bersama masa pembatalan, dan jawapan good bermaksud pembatalan anda tidak sampai kepada responden yang ditanya oleh klien anda. Kemudian jalankan openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem untuk melihat keputusan yang sama melalui laluan senarai. Baca rentetan sebab dan bukan kod keluar, kerana penolakan pembatalan dan ralat rantaian kedua-duanya berakhir dengan kegagalan.

Langkah yang benar-benar penting ialah yang terakhir: sambung semula dengan profil lama terhadap titik penguatkuasaan sebenar dan sahkan penolakan itu datang daripada pembatalan. Kemudian sambung semula dengan sijil baharu yang sah untuk membuktikan anda tidak sekadar merosakkan pendengar. Memadam profil pada klien tidak membuktikan apa-apa tentang keputusan pelayan, dan begitu juga pelaksanaan openssl verify yang berjaya pada mesin yang tidak pernah menamatkan terowong. RFC 6960 mentakrifkan apa yang terkandung dalam respons OCSP yang mematuhi piawaian, termasuk nilai status yang dibaca oleh ujian ini.