it-swarm-id.com

Seberapa layak CA untuk diretas? Sertifikat root tepercaya default manakah yang harus saya hapus?

Pertanyaan ini telah direvisi & diklarifikasi secara signifikan sejak versi aslinya.

Jika kita melihat setiap sertifikat tepercaya di toko Root Tepercaya saya, berapa yang harus saya percayai?

Faktor-faktor apa yang harus dipertimbangkan ketika saya mengevaluasi kepercayaan dari masing-masing Root CA untuk kemungkinan penghapusan dari toko lokal saya?

Informasi Lebih Lanjut:
Jika CA mengeluarkan sertifikat kepada pihak yang divalidasi secara tidak benar, maka hal itu menyebabkan semua mesin yang percaya bahwa CA rentan terhadap serangan MITM. Akibatnya semua CA secara ketat memvalidasi pemohon permintaan sertifikat SSL yang diberikan untuk memastikan integritas rantai CS mereka.

Namun, sebagian besar dari proses verifikasi CA ini tunduk pada intervensi manusia dan memberikan peluang untuk mengeluarkan sertifikat kepada pihak yang salah. Ini dapat dilakukan oleh kesalahan operator CA, tuntutan pemerintah, atau mungkin paksaan (suap) dari operator CA.

Saya ingin mempelajari lebih lanjut tentang CA default mana yang lebih mungkin mengeluarkan sertifikat kepada pihak yang salah. Saya bermaksud menggunakan informasi ini untuk menyarankan pengguna untuk menghapus CA itu dari Toko Sertifikat Tepercaya mereka

Contoh:
Misalkan pemerintah mengendalikan CA tertentu ingin mengambil identitas Microsoft.com, dan menuntut pengecualian untuk proses verifikasi CA. Pemerintahan itu kemudian juga mensyaratkan kerahasiaan pengecualian ini dipertahankan. Pasangan kunci yang dihasilkan kemudian akan digunakan dalam serangan MITM.

Kepercayaan Default Windows Azure

Windows Azure mendukung 275 CA seperti yang ditunjukkan pada tautan berikut . Tergantung pada penggunaan CA tertentu, beberapa CA tersebut dapat meningkatkan luas permukaan serangan tertentu. Bahkan ini mungkin diperlukan secara teknis untuk membuat beberapa aplikasi berfungsi dengan benar.

Amazon Default Trust

(tidak tersedia) Silakan bagikan tautan ke daftar CA default VMWare, Amazon, dan VMWare jika Anda menemukannya.

Mozilla

A daftar semua sertifikat dan laporan audit tersedia.

Apple iOS

Daftar semua sertifikat root iPhone sebagaimana disebutkan dalam ini # WWDC2017. Video

84

Pembaruan 5 Masalah root (heh) dengan model CA adalah bahwa dalam praktik umum, CA apa pun dapat mengeluarkan sertifikat untuk domain apa pun, sehingga Anda rentan ke tautan terlemah. Mengenai siapa yang dapat Anda percayai, saya ragu bahwa daftarnya sangat panjang, karena taruhannya tinggi dan keamanannya sulit. Saya merekomendasikan posting Christopher Soghoian tentang masalah ini, yang mengklarifikasi berbagai pendekatan yang digunakan pemerintah di seluruh dunia untuk mendapatkan akses ke data pengguna pribadi - baik dengan secara langsung menuntutnya dari perusahaan yang mengoperasikan layanan cloud, melalui penyadapan, atau semakin meningkat sekarang melalui paksaan CA atau retasan: sedikit paranoia: Kekuatan yang menyebabkan peretasan DigiNotar .

Di sini saya memberikan beberapa spesifik, dan diakhiri dengan tautan ke beberapa perbaikan potensial.

Pada tahun 2009, Etisalat (60% dimiliki oleh pemerintah Uni Emirat Arab), meluncurkan patch BlackBerry yang tampak tidak berbahaya yang memasukkan spyware ke dalam perangkat RIM, memungkinkan pemantauan email, sehingga hampir tidak dapat dianggap dapat dipercaya. Tetapi ini ada dalam banyak daftar CA tepercaya: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Pembaruan 1 Lihat juga contoh serangan yang berhasil, yang diduga oleh orang Iran bernama ComodoHacker , terhadap Comodo: Sertifikat SSL palsu ("case comodogate") - Weblog F-Secure . F-Secure mencatat bahwa Mozilla menyertakan sertifikat yang dikeluarkan oleh CA di Cina, Israel, Bermuda, Afrika Selatan, Estonia, Rumania, Slovakia, Spanyol, Norwegia, Kolombia, Prancis, Taiwan, Inggris, Belanda, Turki, AS, Hong Kong, Jepang , Hongaria, Jerman dan Swiss.

Tunisia adalah negara lain yang menjalankan CA yang dipercaya secara luas, dan ada juga dokumentasi yang bagus tentang tindakan pemerintah mereka untuk menyerang privasi: Kisah Di Dalam Cara Facebook Menanggapi Hacks Tunisia - Alexis Madrigal - Teknologi - Atlantik

Mozilla mencatat praktik lain yang patut dipertanyakan yang harus diperhatikan: CA yang memungkinkan mitra RA mengeluarkan sertifikat langsung dari root, alih-alih melalui perantara: Masalah Sertifikat Comodo - Tindak Lanjut di Mozilla Security Blog .
Lihat juga lebih detail, termasuk spekulasi tentang klaim tanggung jawab oleh satu peretas Iran Peramban Web dan Comodo Mengungkap Serangan Otoritas Sertifikat yang Berhasil, Mungkin Dari Iran | Kebebasan untuk Tinker

Pembaruan 3 : Serangan sukses lainnya yang tampaknya juga dilakukan oleh ComodoHacker bertentangan dengan DigiNotar CA. Situs web mereka dikompromikan mulai tahun 2009, tetapi ini tidak diketahui sampai setelah DigiNotar juga digunakan pada tahun 2011 oleh Iran untuk menandatangani sertifikat palsu untuk situs web Google, Yahoo !, Mozilla, WordPress dan Proyek Tor. DigiNotar tidak mengungkapkan pengetahuannya tentang intrusi ke dalam situsnya selama lebih dari sebulan. Lihat lebih banyak di DigiNotar Hack Menyorot Kegagalan Kritis Model Keamanan Web SSL kami | Freedom to Tinker .

Saya kira rentang kerentanan berbagai CA sangat beragam, demikian pula utilitasnya. Jadi saya sarankan memfokuskan kembali strategi Anda. Saat Anda dapat mempersempitnya ke aset tertentu yang Anda coba lindungi, cukup hapus semua CA kecuali yang diperlukan untuk menggunakan aset tersebut. Kalau tidak, pertimbangkan untuk menghilangkan CA yang Anda nilai paling rentan terhadap mereka yang peduli dengan aset Anda, atau paling tidak populer, hanya untuk mengurangi permukaan serangan. Tapi terima fakta bahwa Anda akan tetap rentan terhadap serangan canggih bahkan terhadap CA yang paling populer dan berhati-hati.

Pembaruan 2 : Ada pos bagus untuk memperbaiki infrastruktur CA berbahaya kami di Freedom to Tinker: Membangun infrastruktur CA yang lebih baik

Ini berbicara tentang inovasi ini:

Pembaruan 4 Salah satu posting blog Keamanan IT kami pada bulan Agustus 2011 juga mencakup kasus untuk pindah ke DNSSEC: Pandangan Berbasis Risiko saat Memperbaiki Masalah Otoritas Sertifikat "Stack Exchange Security Blog

Pembaruan 6 Beberapa Otoritas Sertifikat telah tertangkap melanggar aturan. Itu termasuk agen cyberdefense Perancis (ANSSI), dan Trustwave, yang masing-masing terkait dengan spoofing sertifikat digital .

Pembaruan 7 Satu lagi rangkaian "sertifikat yang salah", melalui Kontroler India dari Otoritas Sertifikasi (India CCA) pada tahun 2014: Keamanan Online Google Blog: Menjaga keamanan sertifikat digital

Lihat juga pertanyaan tentang Transparansi Sertifikat yang terlihat seperti pendekatan yang membantu untuk menemukan sertifikat yang buruk dan pelanggaran kebijakan sebelumnya.

64
nealmcb

Seperti yang pernah ditulis Matt Blaze, CA melindungi Anda dari siapa pun yang tidak mau mereka ambil uangnya. Itu akan memberi tahu Anda sesuatu tentang di mana insentif CA berada, dan beberapa risiko potensial dalam pengaturan tersebut.

38
D.W.

Saya takut bahwa jawaban singkat untuk pertanyaan ini adalah bahwa tidak mungkin untuk mengetahui, sejauh yang saya lihat. Ada sejumlah besar CA default yang dipasang di browser yang paling umum dan menilai seberapa besar kemungkinan mereka "dapat dipercaya" dalam hal memberikan sertifikat kepada pemerintah atau organisasi lain itu sulit.

Jika CA dikenal sebagai tidak dapat dipercaya maka mereka kemungkinan akan dihapus dari daftar instalasi default browser, (per @xce di bawah, Diginotar adalah contoh yang baik di sini dan juga Digicert)

Selain organisasi yang memberikan sertifikat secara sukarela, ada risiko bahwa mereka dapat memberikan sertifikat tanpa melakukan pemeriksaan keamanan yang sesuai pada pemohon. Di Defcon beberapa tahun yang lalu ada beberapa presentasi tentang tema ini untuk bisa mendapatkan sertifikat tanpa otorisasi.

Jika ini merupakan masalah yang signifikan, satu-satunya cara yang dapat saya pikirkan adalah membuat daftar putih CA yang telah Anda ulas dan merasa nyaman dengan keamanan yang disediakan. Jelas ini tidak akan berfungsi untuk mengakses Internet secara umum karena Anda kemungkinan besar akan menghapus CA yang memiliki masalah Sertifikat ke situs yang ingin Anda gunakan.

18
Rory McCune

2 contoh yang masuk ke jantung dari apa yang perlu Anda ketahui, tetapi bukan apa yang Anda tanyakan secara eksplisit:

  • Beberapa tahun yang lalu (2006, atau mungkin akhir 2005) ada insiden phishing SSL yang dipublikasikan dengan cukup baik - situs web bank palsu menerima sertifikat SSL yang sah (dari GeoTrust, saya percaya), karena kesalahan mengeja situs bank regional. (Pembaruan: ditemukan tautan bersejarah ini - alamatnya adalah nama lengkap bank alih-alih singkatan yang disingkat). Sejak itu, ada kasus-kasus lain dari phishing SSL .... Poinnya adalah mungkin untuk mendapatkan sertifikat tanpa menggunakan "paksaan".
  • Novel terbaru Stuxnet mengandalkan, di antara taktik lain, sertifikat yang dicuri. Ini "dipinjam" dari produsen driver pihak ke-3, dan karena mereka "tepercaya", dapat disalahgunakan untuk menanam malware.

Maka tentu saja, ada skenario perangkat lunak di mana CA bahkan tidak digunakan - mis. dengan klien tebal yang memanggil Layanan Web, yang tidak repot memvalidasi sertifikat server ....

Maksud saya adalah bahwa jika Anda khawatir tentang MITM melalui SSL, lebih sering daripada tidak, itu bukan paksaan pemerintah yang seharusnya membuat Anda khawatir. Biasanya ada cara yang lebih mudah dan lebih mudah diakses.
Saya bahkan keberatan dengan "Sertifikat Tepercaya" yang disebut "Tepercaya" ... Hanya karena saya tahu siapa Anda, bukan berarti saya harus memercayai Anda ... dan itu tidak berarti saya harus percaya bahwa Anda tahu siapa seseorang. else adalah.

Belum lagi, bahwa jika Anda menghapus sertifikat root standar dari toko tepercaya, banyak situs di internet tidak akan berfungsi seperti yang diharapkan.

Di sisi lain, jika Anda berurusan dengan server/alat yang tidak memerlukan kemampuan penelusuran umum, tetapi berkomunikasi dengan server tertentu (atau set server), pasti hapus [~ # ~] semua [~ # ~] sertifikat root, kecuali daftar putih dari yang Anda butuhkan.
Dan jika Anda menggunakan CA internal Anda sendiri, bahkan lebih baik ....

11
AviD

Setiap CA menerbitkan Pernyataan Praktik Sertifikat yang menjelaskan bagaimana mereka melindungi kunci mereka sendiri, dan memvalidasi permintaan untuk sertifikat sebelum menerbitkannya. URL ke lokasi untuk dokumen ini biasanya tertanam di setiap sertifikat yang dikeluarkan oleh CA. Dengan asumsi bahwa CA yang dimaksud benar-benar mengikuti dokumen kebijakan ini, ia harus memberi Anda indikasi lamanya mereka pergi untuk memastikan validitas entitas yang meminta sertifikat. Cari pernyataan yang menyatakan bahwa mereka melindungi kunci penandatanganan CA mereka menggunakan Modul Keamanan Perangkat Keras atau Modul Kriptografi untuk melindungi kunci penandatanganan, otentikasi multi-faktor, dan otorisasi berbasis kuorum untuk menandatangani sertifikat, dll. Metode perlindungan ini menjadikannya jauh lebih sulit dan lebih mahal. untuk pihak ketiga jahat mencuri kunci penandatanganan.

Daftar besar CA tepercaya (Keychain Root System Mac saya memiliki 175) ada untuk kenyamanan Anda, untuk membuat sistem HTTPS dapat digunakan untuk Anda dan semua orang di planet ini yang tidak mengajukan pertanyaan ini. Anda dapat, tentu saja, mengeluarkan setiap CA dari daftar ini kecuali jika Anda secara pribadi telah mengaudit praktik mereka. Untuk sistem tertutup, di mana Anda mengontrol semua titik akhir dan Anda memiliki sejumlah pihak tepercaya, ini bisa dilakukan. Sistem kontrol versi Subversion tidak termasuk sertifikat Root tepercaya, tetapi Anda dapat menambahkan sendiri ke setiap klien. Untuk web pada umumnya, satu-satunya cara yang kami temukan untuk membuatnya dapat digunakan adalah dengan memiliki pihak tepercaya out-of-band (perusahaan yang memasok sistem operasi atau browser Anda, apa pun yang Anda pikirkan) menyediakan daftar tepercaya sertifikat yang memungkinkan Anda terhubung ke hampir semua server berkemampuan SSL di dunia.

Apakah Anda benar-benar membutuhkan semua sertifikat itu dalam daftar tepercaya Anda? Mungkin tidak. Tetapi vendor OS/peramban Anda tidak dapat mengantisipasi (dan tidak seharusnya mengontrol) dengan siapa Anda ingin berbisnis, sehingga mereka menyertakan semuanya. Masalah dengan daftar besar adalah bahwa Anda memiliki CA dari semua bulu, dengan semua jenis metode verifikasi, dari semua yurisdiksi, diperlakukan sama persis. Tidak setiap CA bertindak sama: kami telah melihat kasus kredensial login reseller yang dikompromikan, dan bahkan dikompromikan kunci CA. Beberapa CA membutuhkan sertifikat penggabungan dan janji anak sulung Anda, yang lain hanya memverifikasi bahwa Anda dapat menerima email pada domain yang Anda minta sertifikatnya. Namun setiap CA diperlakukan sama persis dengan browser Anda.

Garis pertahanan terhadap sertifikat jahat untuk Nama Umum yang sama adalah untuk men-cache sertifikat asli pada klien: jika sertifikat yang berbeda dari CA yang berbeda tiba-tiba muncul, ini harus menjadi perhatian. Saya tidak tahu bagaimana browser hari ini menangani kasus ini, dan saya terlalu malas untuk mengetahuinya.

9
Sander Temme

Diskusi semacam ini selalu mengingatkan saya pada bug Mozilla ini meminta dimasukkannya CA baru. Cukup lucu, tapi cukup wawasan.

4
Steve Dispensa

Saat meneliti sertifikat mana yang harus dihapus di PC Windows, Anda harus terlebih dahulu memastikan Anda tidak menghapus sertifikat yang diperlukan sistem. Jika Anda mencoba melakukannya, Anda akan mendapatkan pesan kesalahan berikut

error- you're deleting a system cert!!

Ini adalah URL dengan daftar sertifikat yang tidak boleh dihapus dari sistem windows http://support.Microsoft.com/?id=293781

Selanjutnya Anda harus mempertimbangkan untuk menghapus (menguji penghapusan) sertifikat perantara, karena hanya ada " murni untuk alasan warisan ".

Saat mengevaluasi penghapusan semua sertifikat yang tersisa, pertimbangkan bahwa Program Sertifikat Microsoft Root mengharuskan CA untuk melewati salah satu standar audit ini:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust untuk CA
  • Web Audit kesiapan EV Aman
  • ISO 21188 (Perhatikan bahwa mereka tidak menerima ISO 27001)

Jika Anda menghapus Certs dari browser non MSFT (IE) maka Anda mungkin ingin tinjau panduan kualitas CA ini .

Batasan

Program ini juga memiliki audit tambahan yang berlaku untuk apa Penggunaan Kunci. Penggunaan utama terbatas pada hal-hal berikut:

  • Otentikasi Server (SSL) = 1.3.6.1.5.5.7.3.1

  • Otentikasi Klien (SSL) = 1.3.6.1.5.5.7.3.2

  • E-mail Aman (SMIME) EKU = 1.3.6.1.5.5.7.3.4

  • Penandatanganan Kode EKU = 1.3.6.1.5.5.7.3.3

  • Time stamping EKU = 1.3.6.1.5.5.7.3.8

  • OCSP EKU = 1.3.6.1.5.5.7.3.9

  • Mengenkripsi Sistem File EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (Tunnel, User) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Penggunaan Kunci yang Dilarang

Penggunaan utama berikut dilarang oleh program:

  • Log masuk kartu pintar Ini adalah skenario perusahaan saja, karena penyebaran Direktori Aktif diperlukan dan root harus ditambahkan ke toko NTAuth di Direktori Aktif. Lihat artikel KB berikut untuk detailnya. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245

  • Hak digital EKU ini sudah usang. Windows Media DRM menggunakan format XML sendiri untuk lisensi dan tidak menggunakan X.509.

  • Subordinasi yang memenuhi syarat EKU ini sudah usang dan diabaikan oleh Windows.

  • Skenario CA Enterprise pemulihan kunci.

  • Pemulihan file EKU ini sudah usang dan diabaikan oleh Windows Encrypting File System (EFS).

  • Semua kebijakan aplikasi Kami tidak dapat memberikan "semua penggunaan" karena ini tentu saja mengakui EKU hanya perusahaan dan lainnya yang tidak dapat diterima.

  • Skenario perusahaan Layanan replikasi email direktori

  • Agen permintaan sertifikat

  • Skenario CA perusahaan

  • Skenario pemulihan agen kunci Enterprise CA

  • Sertifikat enkripsi CA

  • Skenario CA perusahaan

Kriteria Penerimaan

Selain itu kriteria berikut harus dipenuhi sebelum menambahkan tujuan umum atau Pemerintah CA ke root:

  1. CA harus memberikan informasi yang diminta di bawah ini (lihat Langkah 1. Hubungi Microsoft ), dan menerima persetujuan awal untuk keanggotaan dalam Program.

  2. CA harus memberikan sertifikat uji yang dikeluarkan dari sertifikat root CA untuk tujuan pengujian. Secara opsional, CA dapat memberikan kepada Microsoft URL dari server yang dapat diakses publik di mana sertifikat yang dikeluarkan dari sertifikat root mereka dapat diverifikasi. (Lihat FAQ untuk detail)

  3. CA harus menyelesaikan Perjanjian CA Microsoft. Perjanjian akan diberikan hanya setelah Anda menyelesaikan Langkah 1 dari proses aplikasi dan menerima persetujuan awal dari aplikasi Anda.

  4. Sertifikat root harus mematuhi bagian Persyaratan Teknis di bawah ini. Secara khusus, kami memerlukan ukuran kunci kripto minimum dari modulus RSA 2048-bit untuk setiap root dan semua CA yang mengeluarkan. Microsoft tidak akan lagi menerima sertifikat root dengan modulus RSA 1024-bit dari kedaluwarsa apa pun. Kami lebih suka bahwa root baru berlaku untuk setidaknya 8 tahun sejak tanggal pengiriman tetapi berakhir sebelum tahun 2030, terutama jika mereka memiliki modulus RSA 2048-bit.

  5. Sertifikat yang dikeluarkan dari sertifikat root harus mendukung ekstensi titik distribusi CRL. Titik distribusi CRL harus mengarah ke lokasi yang dapat diakses publik.

  6. CA harus memiliki kebijakan pencabutan yang terdokumentasi, dan CA harus dapat mencabut sertifikat apa pun yang mereka keluarkan.

  7. CA harus menyelesaikan audit dan menyerahkan hasil audit ke Microsoft setiap dua belas (12) bulan. Audit harus mencakup hierarki PKI lengkap yang akan diaktifkan oleh Microsoft melalui penugasan Penggunaan Kunci yang Diperluas (EKU). Semua penggunaan sertifikat yang kami aktifkan harus diaudit secara berkala. Laporan audit harus mendokumentasikan ruang lingkup penuh hirarki PKI termasuk setiap sub-CA yang mengeluarkan jenis sertifikat tertentu yang dicakup oleh audit. Audit yang memenuhi syarat meliputi:

Ini adalah audit yang diterima saat ini untuk CA non-pemerintah. Kami berhak untuk mengubah audit yang tercantum di atas dan/atau menerima audit lain yang sebanding di masa mendatang.

Persyaratan Teknis

Sertifikat root baru harus memenuhi persyaratan teknis berikut:

  • Sertifikat root harus berupa sertifikat x.509 v3.

  • Nama Subjek harus mengandung nama yang bermakna dari CA (mis. Tidak boleh "Root" atau "CA1")

  • Ekstensi Basic Constraints: cA = true

  • Penggunaan Kunci (jika ada): keyCertSign dan cRLSign saja

  • Persyaratan Ukuran Kunci Root didasarkan pada NIST SP 800-57:

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • Algoritma hash harus setidaknya SHA1. Tidak ada hash MD2, MD4 atau MD5 yang diterima.

  • Untuk ukuran kunci akar lebih besar atau sama dengan modulus RSA 2048-bit, sertifikat akar tidak boleh kedaluwarsa hingga minimal 8 tahun setelah pengiriman dan tidak lebih dari 2030. Kedaluwarsa yang lebih lama mungkin diberikan ke ukuran kunci akar yang lebih besar.

  • Sertifikat CA perantara dikeluarkan dari Program CA Root (Lihat Pertanyaan yang Sering Diajukan untuk informasi lebih lanjut)

  • CA tidak akan mengeluarkan sertifikat bawahan atau entitas akhir MD2, MD4 atau MD5 dari sertifikat akar apa pun yang didistribusikan oleh Program, efektif 15 Januari 2009.

  • Sertifikat root RSA 1024 bit yang ada ("warisan") dapat tetap didistribusikan oleh Program hingga batas waktu NIST pada tanggal 31 Desember 2010, kecuali seperti yang disediakan oleh Microsoft.

  • CA dapat mengeluarkan sertifikat RSA 1024-bit dari sertifikat root yang didistribusikan oleh Program hingga batas waktu NIST pada tanggal 31 Desember 2010.

3

Saya percaya pemerintah AS mencoba untuk meloloskan undang-undang beberapa tahun yang lalu memberi mereka hak untuk memaksa CA untuk menghasilkan sertifikat yang valid dari pihak ke-3 untuk penyadapan dan apa-tidak. Saya tidak dapat menemukan bukti tentang ini, jadi saya mungkin mengingat sesuatu di sepanjang garis pembicaraan DefCon yang disebutkan Rory.

3
Steve

Misalkan beberapa pemerintahan yang buruk ingin melihat lalu lintas SSL mesin. Seberapa layak CA default harus dipaksa menerbitkan sertifikat baru?

Predikat dan pertanyaannya tidak berhubungan. Tidak masalah seberapa mudah atau sering CA dapat dipaksa mengeluarkan sertifikat baru - calon penyadap tidak dapat melihat data Anda kecuali mereka memiliki kunci pribadi dari sertifikat yang telah Anda instal. IIRC (tapi saya akan merekomendasikan memeriksa ini) CSR tidak termasuk kunci pribadi - sehingga CA tidak bisa mendapatkannya dengan cara itu. Mereka tidak dapat mengubah kunci apa yang digunakan mesin Anda.

Namun, ada kemungkinan bahwa CA jahat dapat mengeluarkan sertifikat palsu - dan kemungkinan ada untuk serangan MITM di situs Anda. Masalah terbaru dengan format MD5 dan Etisalat menyarankan itu bukan tidak mungkin.

3
symcbean

Mencoba fokus pada pertanyaan kedua.

Masalah "Sertifikat root tepercaya default apa yang harus saya hapus?" pada dasarnya tergantung pada siapa Anda berurusan.

Anda "hanya" perlu mempercayai semua CA yang menandatangani salah satu situs web yang Anda sambungkan.

Untuk pengguna tipe nenek yang selalu mengunjungi beberapa situs yang sama, mungkin beberapa CA akan cukup, sedangkan daftar tidak akan begitu cepat * tumbuh untuk pengguna internet yang berat.

Mengapa tidak begitu cepat ? Sebaliknya, beberapa CA banyak digunakan (termasuk yang terlalu besar untuk gagal) sementara yang lain hanya jarang digunakan di internet, seperti yang hampir secara geografis.

Alat SSLCop from securitybydefault dapat membantu memblokir dari negara-negara yang tidak Anda percayai/tidak mungkin membutuhkan (mis. Anda tidak mengharapkan akses ke situs web dari pemerintah Brobdingnag, yang kebetulan menjadi pengguna utama CA itu): http://www.security-projects.com/?SSLCop

Namun, jika Anda tidak mempercayai terlalu banyak CA, Anda pada akhirnya tidak akan bisa mendapatkan jangkar kepercayaan ke situs web yang dibutuhkan pengguna Anda (dan mereka akan mengaksesnya Lagi pula, meskipun peringatan keamanan), yang sama buruknya.

1
Ángel

Demonstrasi membuat CA nakal menggunakan kelemahan MD5:

1
Bradley Kreider

Pada 12 Juni 2012 Microsoft merilis pembaruan baru yang akan menonaktifkan sertifikat root tidak dipercaya dan sertifikat lainnya yang dilaporkan ke Microsoft sebagai tidak dapat dipercaya.

Pembaruan tersedia di sini, dan saya tidak yakin apakah pembaruan ini telah didistribusikan melalui Pembaruan Windows, atau apakah pembaruan ini keluar dari band.

http://support.Microsoft.com/kb/267707

0