Artikel ini pada asalnya diterbitkan pada Blog Scott Helme dan dicetak semula di sini dengan izinnya.
Kami mempunyai sedikit masalah di web sekarang dan saya hanya dapat melihatnya menjadi kebimbangan yang lebih besar seiring dengan berlalunya masa: semakin banyak laman web mendapatkan sijil, dokumen penting yang diperlukan untuk menggunakan HTTPS, tetapi kami tidak mempunyai cara untuk melindungi diri sendiri perkara yang salah.
sijil
Kami sedang melihat sedikit perolehan emas untuk sijil di Web kerana semakin banyak laman web menggunakan HTTPS. Di luar faedah keselamatan dan privasi HTTPS yang jelas, terdapat beberapa sebab yang mungkin anda ingin pertimbangkan untuk beralih ke sambungan selamat yang saya gariskan dalam artikel saya Masih fikir anda tidak memerlukan HTTPS?. Biasanya disebut sebagai "sijil SSL" atau "sijil HTTPS", Internet yang lebih luas memperolehnya dengan kadar yang belum pernah kita lihat sebelumnya dalam sejarah web. Setiap hari saya merangkak satu juta laman web teratas di Web dan menganalisis pelbagai aspek keselamatan mereka dan setiap 6 bulan saya menerbitkan laporan. Anda boleh melihat laporannya disini, tetapi hasil utama yang ditumpukan sekarang adalah penggunaan HTTPS.
Kami bukan sahaja terus menyebarkan HTTPS, tetapi kadar yang kami lakukan juga meningkat. Inilah rupa kemajuan sebenar. Proses mendapatkan sijil menjadi semakin mudah dari semasa ke semasa dan sekarang, terima kasih kepada yang luar biasa Ayo Sulitkan, juga percuma untuk mendapatkannya. Sederhananya, kami mengirimkan Permintaan Penandatanganan Sijil (CSR) ke Lembaga Sijil (CA) dan CA akan mencabar kami untuk membuktikan pemilikan domain kami. Ini biasanya dilakukan dengan menetapkan rekod TXT DNS atau menghosting kod cabaran di suatu tempat di jalan rawak di domain kami. Setelah cabaran ini dipenuhi, CA akan mengeluarkan sijil dan kemudian kami dapat menyampaikannya kepada pelayar pelawat dan mendapatkan gembok hijau dan "HTTPS" di bar alamat.
Saya mempunyai beberapa tutorial untuk membantu anda dengan proses ini, termasuk bagaimana bermula, bagaimana untuk menubuhkan pembaharuan pintar, dan bagaimana untuk digunakan sijil dwi. Jadi, ini semua bagus. Apa masalahnya?
Masalahnya adalah apabila perkara tidak berjalan sesuai dengan rancangan dan anda mengalami hari yang buruk.
"Kami telah diretas!"
Tidak ada yang mahu mendengar kata-kata itu, tetapi kenyataan yang menyedihkan adalah yang kita lakukan — lebih kerap daripada yang kita mahukan. Penggodam dapat mengejar banyak perkara apabila mereka mendapat akses ke pelayan kami dan selalunya salah satu perkara yang dapat mereka akses adalah kunci peribadi kami. Sijil yang kami gunakan untuk HTTPS adalah dokumen awam — kami menghantarnya kepada sesiapa sahaja yang menyambung ke laman web kami — tetapi perkara yang menghentikan orang lain menggunakan sijil kami adalah mereka tidak mempunyai kunci peribadi kami. Apabila penyemak imbas membuat sambungan selamat ke laman web, ia memeriksa bahawa pelayan mempunyai kunci peribadi untuk sijil yang cuba digunakan, dan inilah sebabnya mengapa tidak ada orang lain kecuali kami yang dapat menggunakan sijil kami. Sekiranya penyerang mendapat kunci peribadi kami, keadaan akan berubah.
Setelah penyerang berjaya mendapatkan kunci peribadi kami, mereka dapat menggunakan sijil kami untuk membuktikan bahawa mereka adalah kami. Katakan sekali lagi: jika kunci anda dicuri, itu bermakna ada seseorang di Internet bukan awak, yang boleh membuktikan bahawa mereka adalah awak. Ini adalah masalah yang sebenarnya, dan sebelum anda berfikir "ini tidak akan pernah terjadi pada saya," anda harus ingat Heartbleed. Bug kecil di perpustakaan OpenSSL ini membolehkan penyerang mencuri kunci peribadi dan anda bahkan tidak perlu melakukan sesuatu yang salah agar ia berlaku. Selain itu terdapat banyak cara bahawa kunci peribadi terdedah secara tidak sengaja atau kecuaian. Kebenaran sederhana adalah bahawa kita boleh kehilangan kunci peribadi kami, dan apabila ini berlaku, kami memerlukan cara untuk menghentikan penyerang menggunakan sijil kami. Kita perlu membatalkan sijil itu.
Pembatalan
Dalam senario kompromi kami membatalkan sijil kami sehingga penyerang tidak dapat menyalahgunakannya. Setelah sijil ditandai sebagai "dicabut," penyemak imbas Web akan tahu untuk tidak mempercayainya, walaupun sijil itu sah. Pemilik telah meminta pembatalan dan tidak ada pelanggan yang harus menerimanya.
Setelah mengetahui bahawa kami telah membuat kompromi, kami menghubungi CA dan meminta mereka membatalkan sijil kami. Kami perlu membuktikan kepemilikan sijil yang dimaksudkan, dan setelah kami melakukannya, CA akan menandakan sijil sebagai dicabut. Setelah sijil dicabut, kami memerlukan cara untuk menyampaikan pembatalan ini kepada mana-mana pelanggan yang mungkin memerlukan maklumat tersebut. Selepas pembatalan, penyemak imbas pelawat tidak tahu mengenainya - dan tentu saja, itu adalah masalah. Terdapat dua mekanisme yang dapat kita gunakan untuk menyediakan maklumat ini: Senarai Pembatalan Sijil (CRL), atau Protokol Status Sijil Dalam Talian (OCSP).
Senarai Pembatalan Sijil
CRL adalah konsep yang benar-benar mudah dan sememangnya hanya satu senarai semua sijil bahawa CA telah ditandakan sebagai dibatalkan. Pelanggan boleh menghubungi Pelayan CRL dan memuat turun satu salinan senarai. Berbekalkan salinan senarai penyemak imbas boleh menyemak untuk melihat apakah sijil yang telah disediakan adalah pada senarai itu. Sekiranya sijil itu is Dalam senarai itu, penyemak imbas kini mengetahui bahawa sijilnya tidak baik dan tidak boleh dipercayai. Penyemak imbas harus melepaskan ralat dan memutuskan sambungan. Sekiranya sijil tidak ada dalam senarai, semuanya baik-baik saja dan penyemak imbas boleh meneruskan sambungan.
Masalah dengan CRL adalah bahawa mereka mengandungi banyak sijil yang dibatalkan dari CA tertentu yang mengekalkannya. Tanpa terlalu banyak terperinci, mereka dipecah oleh setiap sijil perantaraan yang dimiliki oleh CA dan CA dapat memecah daftar menjadi beberapa bahagian yang lebih kecil. Terlepas dari bagaimana ia dipecah, intinya saya ingin tetap sama: CRL biasanya bukan ukuran yang tidak signifikan. Masalah lain ialah jika pelanggan tidak mempunyai salinan CRL yang baru, ia mesti mengambilnya semasa sambungan awal ke laman web anda — yang boleh menjadikan laman web anda kelihatan lebih perlahan daripada yang sebenarnya.
Kedengarannya tidak begitu hebat — jadi bagaimana kita melihat OCSP?
Protokol Status Sijil Atas Talian
OCSP menyediakan penyelesaian yang lebih baik untuk masalah ini dan mempunyai kelebihan yang signifikan terhadap pendekatan CRL. Dengan OCSP, kami meminta CA untuk status sijil tunggal, khusus. Ini bermakna semua yang perlu dilakukan CA adalah bertindak balas dengan jawapan yang baik / dibatalkan, yang jauh lebih kecil daripada CRL. Barang-barang hebat!
Memang benar bahawa OCSP menawarkan kelebihan prestasi yang signifikan daripada mengambil CRL, tetapi, kelebihan prestasi itu datang dengan kos (tidakkah anda membencinya ketika itu berlaku?). Kosnya juga cukup besar: privasi anda.
Apabila kita memikirkan apa itu permintaan OCSP - permintaan untuk status sijil tunggal yang sangat khusus - anda mungkin mula menyedari bahawa anda membocorkan beberapa maklumat. Apabila anda menghantar permintaan OCSP, anda pada dasarnya meminta CA:
Adakah sijil untuk pornhub.com sah?
Jadi, bukan betul-betul senario yang ideal. Anda sekarang mengiklankan sejarah penyemakan imbas anda kepada pihak ketiga yang bahkan tidak anda ketahui, semuanya atas nama HTTPS — yang bertujuan memberi kami lebih banyak keselamatan dan privasi. Jenis ironis, ya?
Kegagalan keras
Tetapi tunggu: ada perkara lain. Saya bercakap mengenai tindak balas CRL dan OCSP di atas, dua mekanisme yang boleh digunakan penyemak imbas untuk memeriksa sama ada sijil dicabut. Mereka kelihatan seperti ini.
Setelah menerima sijil, penyemak imbas akan menjangkau salah satu perkhidmatan ini dan melakukan pertanyaan yang diperlukan untuk akhirnya memastikan status sijil. Tetapi bagaimana jika CA anda mengalami hari yang buruk dan infrastruktur di luar talian? Bagaimana jika ia kelihatan seperti ini?
Penyemak imbas hanya mempunyai dua pilihan di sini. Ia boleh menolak untuk menerima sijil kerana tidak dapat memeriksa status pembatalan, atau dapat mengambil risiko dan menerima sijil tanpa mengetahui status pembatalan. Kedua-dua pilihan ini hadir dengan kelebihan dan kekurangan mereka. Sekiranya penyemak imbas enggan menerima sijil itu, maka setiap kali CA anda mengalami hari yang buruk dan infrastruktur mereka tidak berfungsi, laman web anda juga akan offline. Sekiranya penyemak imbas terus dan menerima sijil maka berisiko menggunakan sijil yang mungkin telah dicuri, dan mendedahkan pengguna kepada risiko yang berkaitan dengannya.
Ini adalah panggilan yang sukar - tetapi sekarang, hari ini, kedua-duanya tidak berlaku.