it-swarm-id.com

Kerentanan apa yang dapat disebabkan oleh sertifikat SSL wildcard?

Dalam komentar di jawaban ini , AviD mengatakan:

"Ada banyak masalah keamanan dengan sertifikat SSL wildcard."

Jadi, apa masalahnya? Saya mengerti bahwa kunci privat yang sama sedang digunakan dalam banyak konteks, tetapi mengingat bahwa saya dapat Host semua aplikasi saya di bawah nama Host yang sama saya tidak melihat ini sebagai masalah 'baru' yang diperkenalkan oleh sertifikat wildcard.

46
user185

"Sertifikat wildcard" adalah sertifikat yang berisi, mungkin nama server, nama yang mengandung "* "karakter. Detailnya ada di RFC 2818, bagian 3.1 . Intinya: ketika sertifikat server berisi *.example.com, itu akan diterima oleh klien sebagai sertifikat yang valid untuk server mana pun yang nama jelas cocok nama itu.

Dalam bisnis sertifikasi untuk situs Web, ada empat aktor utama:

  • Server SSL itu sendiri.
  • Penjual browser Web yang akan digunakan klien.
  • Pengguna manusia, yang mengontrol sampai batas tertentu apa yang akan dilakukan browser klien.
  • CA yang menerbitkan sertifikat ke server.

Sertifikat wildcard tidak menyiratkan kerentanan ekstra untuk server SSL; memang, server SSL tidak tertarik melihat sertifikatnya sendiri. Sertifikat itu untuk keuntungan klien, untuk meyakinkan mereka bahwa kunci publik yang terkandung dalam sertifikat memang kunci publik dari server SSL asli. Server SSL tahu pasangan kunci publik/pribadi dan tidak perlu diyakinkan tentang hal itu.

Pengguna manusia tidak tahu apa kunci publik itu. Apa yang dilihatnya adalah ikon gembok dan, yang lebih penting, nama server yang dimaksudkan : itulah nama di sebelah kanan "https:// "dan sebelum berikutnya" / ". Browser Web seharusnya menangani detail teknis memverifikasi bahwa nama itu benar, yaitu validasi sertifikat server, dan verifikasi bahwa nama itu cocok dengan yang tertulis dalam sertifikat tersebut. Jika browser tidak melakukan pekerjaan ini, maka browser akan dianggap ceroboh dan tidak mengambil perannya, yang dapat memiliki konsekuensi komersial yang serius, bahkan mungkin legal. Demikian pula, CA terikat kontrak untuk mengikuti prosedur yang ditentukan untuk mengidentifikasi pemilik server SSL sehingga sertifikat palsu akan sulit diperoleh bagi penyerang (kontrak ada di antara CA dan ug-CA-nya, secara rekursif, hingga root CA yang terikat oleh perjanjian dengan OS atau vendor browser, yang diterima untuk memasukkan kunci CA root dalam OS atau browser dalam kondisi yang ditentukan).

Apa artinya ini, adalah bahwa browser dan [~ # ~] ca [~ # ~] harus, dalam praktiknya , memanjakan pengguna melalui proses verifikasi. Mereka kurang lebih berkewajiban (oleh hukum atau, bahkan lebih keras, dengan pertimbangan bisnis) untuk mencegah pengguna ditipu melalui situs palsu yang terlihat sah. Batas antara pekerjaan pengguna dan pekerjaan browser/CA tidak didefinisikan dengan jelas, dan telah dipindahkan secara historis. Dalam Days of Yore, maksud saya sepuluh tahun yang lalu, browser baru saja mencetak URL mentah, dan terserah pengguna manusia untuk menemukan nama server di dalamnya. Ini mengarahkan para operator situs palsu (yaitu "situs phishing") untuk menggunakan URL yang secara teknis valid, tetapi menyesatkan, seperti ini:

https://www.Paypal.com:[email protected]/confirm.html

Karena pengguna manusia, yah, manusia , dan kebanyakan dari mereka membaca dari kiri ke kanan (target scam yang paling kaya dan mudah tertipu masih di negara-negara Barat), mereka akan mulai pada kiri, lihat www.Paypal.com, berhenti di tanda titik dua ("terlalu teknis"), dan scammed.

Sebagai reaksi, vendor browser telah mengakui bahwa kemampuan penguraian URL dari pengguna manusia tidak sebagus yang diperkirakan sebelumnya, dan dengan demikian browser terbaru menyoroti bagian domain. Dalam kasus di atas, ini akan menjadi xcvhjvb.com, dan tentu saja tidak dengan Paypal.com di dalamnya. Sekarang sampai pada bagian di mana sertifikat wildcard memasuki permainan. Jika pemilik xcvhjvb.com membeli sertifikat wildcard yang mengandung "*.xcvhjvb.com ", lalu dia dapat mengatur situs phishing bernama:

https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html

yang akan diterima oleh browser (cocok dengan nama wildcard), dan masih cenderung untuk menangkap pengguna yang tidak waspada (dan ada banyak ...). Nama ini bisa dibeli oleh penyerang tanpa menggunakan wildcard, tetapi kemudian karyawan CA akan melihat nama itu dengan upaya penipuan yang jelas (CA bagus lakukan validasi manusia atas setiap permintaan sertifikat, atau paling tidak ajukan peringatan untuk nama yang sangat panjang dan/atau mengandung nama bank yang dikenal di dalamnya).

Oleh karena itu, sertifikat wildcard mengurangi efektivitas tindakan penahanan penipuan di sisi CA . Ini seperti tanda tangan kosong dari CA. Jika upaya phishing berbasis wildcard menjadi lebih umum, orang dapat berharap bahwa satu atau beberapa tindakan berikut akan muncul:

  • Browser hanya menyoroti bagian-bagian dari nama domain yang cocok dengan elemen non-wildcard dalam sertifikat.
  • CA membutuhkan dokumen dan kontrak yang lebih berat untuk sertifikat wildcard (dan ini akan lebih mahal).
  • Browser menonaktifkan dukungan untuk sertifikat wildcard sama sekali.

Saya benar-benar berharap ketiga langkah ini akan diterapkan dalam beberapa tahun mendatang. Saya bisa benar-benar salah tentang hal itu (itulah masalah dengan memprediksi masa depan) tetapi ini masih merupakan perasaan saya.


Nitpickingly, kami juga dapat menunjukkan bahwa sertifikat wildcard berguna untuk berbagi pasangan kunci yang sama antara server yang berbeda nama , yang membuatnya lebih mungkin bahwa kunci pribadi akan dibagi antara server yang berbeda mesin . Bepergian kunci pribadi adalah risiko keamanan dalam hak mereka sendiri; semakin banyak kunci privat berkeliaran, semakin sedikit "privat" yang tersisa.

35
Thomas Pornin

Merupakan praktik yang buruk untuk menyebarkan kunci pribadi yang sama di beberapa server yang menyediakan layanan berbeda: Masalah keamanan yang dieksploitasi dalam layanan apa pun akan mengungkapkan kunci pribadi yang digunakan untuk semuanya.

Tetapi adalah umum untuk menggunakan sertifikat wildcard untuk mengisolasi konten web kontribusi pengguna dalam subdomain khusus pengguna untuk memanfaatkan kebijakan Origin yang sama. Pendekatan yang sama biasanya digunakan untuk membuat portlet yang tidak dipercaya. Itu bagian dari Open Social "standard".

Di tempat kerja saya, kami mengembangkan perangkat lunak yang berisi implementasi sosial terbuka dan menggunakan pengaturan wildcard. Instalasi pelanggan telah mengalami tes penetrasi. Pengaturan wildcard tidak dikritik.

18

Pada akhirnya, banyak kerentanan yang dicatat dalam jawaban-jawaban ini berasal dari tingkat kepercayaan campuran. Tetapi jika Anda memahami bagaimana sertifikat wildcard bekerja, Anda dapat mengurangi kerentanan ini untuk kasus penggunaan tertentu. Saya pikir menjelaskan hal ini secara lebih rinci akan meningkatkan kegunaan pertanyaan ini dan jawabannya.

Kecuali semua sistem di domain Anda memiliki tingkat kepercayaan yang sama, menggunakan sertifikat wildcard untuk mencakup semua sistem di bawah kendali Anda adalah ide yang buruk. Tetapi Anda dapat menggunakan subdomain DNS sebagai alat segmentasi. Seperti yang dikatakan Hendrik, karena wildcard tidak melintasi subdomain, Anda dapat membatasi sertifikat wildcard ke namespace tertentu. Misalnya, jika Anda memiliki kebun CDN, Anda dapat melakukan wildcard *.cdn.example.com. Ini membuat host tetap dalam example.com sendiri (seperti www.example.com) terpisah, dan Anda dapat mengeluarkan sertifikat terpisah untuk www.example.com.

Seperti yang disebutkan AviD dari OWASP: stasiun kerja internal, sistem pengembangan, dll. Termasuk dalam tingkat kepercayaan yang lebih rendah. Namun, host seperti ini harus tetap berada dalam ruang domain internal mereka sendiri (seperti prv.example.com). Karena wildcard tidak melintasi subdomain, _ *.example.com cert tidak dapat diterapkan ke prv.example.com host. (Ini akan membuat properti publik dan pribadi terpisah, tetapi jelas tidak memisahkan properti pribadi dari satu sama lain. Wildcard subdomain lainnya dapat digunakan, dipetakan ke tingkat kepercayaan yang sesuai).

Sementara artikel eWeek ini mencatat bahwa kunci pribadi dapat dibagi di beberapa host, bantahan SSLShopper ini mengatakan bahwa beberapa penerbit (seperti DigiCert) memungkinkan Anda untuk membuat kunci pribadi terpisah untuk masing-masing Host wildcarded. Ini memang mengurangi beberapa kegunaan sertifikat wildcard, tetapi jelas meringankan masalah shared-private-keys, dan mungkin membantu dalam beberapa keadaan. Kalau tidak, artikel Entrust ini dan whitepaper PDF yang direferensikan membahas praktik terbaik untuk mengelola kunci privat ketika digunakan dengan sertifikat wildcard.

Akhirnya, beralih ke argumen oleh otoritas ... if Google menggunakan sertifikat wildcard untuk beberapa properti mereka , mereka tidak boleh buruk secara universal:

Qualys SSL Labs screenshot for youtube.com cert

:-)

9
Royce Williams

Idealnya daftar layanan yang dapat digunakan untuk menyamar sebagai sertifikat/kunci harus sama dengan daftar layanan yang akan digunakan untuk sertifikat/kunci tersebut.

Katakanlah Anda memiliki domain example.com. Anda mengatur berbagai nama host di bawah domain tersebut www.example.com catpictures.example.com users.example.com. Semua dihosting di server yang sama sehingga Anda mendapatkan satu sertifikat untuk mencakup semuanya.

Sekarang katakanlah Anda mengatur secure.example.com di server yang lebih aman. Katakanlah Anda mendapatkan sertifikat terpisah untuk server itu.

Sekarang pertimbangkan apa yang terjadi jika kunci pribadi yang terkait dengan sertifikat pada server pertama dicuri.

Jika itu adalah sertifikat untuk * .example.com (sertifikat wildcard) maka penyerang dapat menggunakannya sebagai peniru secure.example.com

Jika itu adalah sertifikat untuk www.example.com catpictures.example.com dan users.example.com maka penyerang tidak dapat menggunakannya untuk menyamar sebagai secure.example.com

4
Peter Green