Paksa Chrome untuk Mengabaikan "kunci publik Diffie-Hellman yang lemah sesaat"

Dengan pembaruan Chrome ke v45, itu memblokir akses ke halaman dengan kunci publik Diffie-Hellman ephermeral yang lemah. Saya mengerti bahwa ini karena Logjam. Saya mengerti bahwa beralih dari https ke http adalah "solusi" dalam beberapa kasus.

Namun, saya tidak dapat beralih dari https ke http karena saya otomatis dialihkan ke https oleh perangkat lunak berbasis web yang kami gunakan di intranet kami.

Jelas, solusinya adalah memiliki keamanan mengubah berbagai server intranet menjadi aman dari logjam, saya mengerti itu, tapi itu bukan pilihan saat ini, dan saya tidak dapat melakukan pekerjaan lagi sampai diperbaiki. Karena ini adalah intranet dan hanya menghubungkan sama sekali mengharuskan seseorang berada di sini secara fisik, risikonya sangat kecil.

Apakah ada cara agar saya dapat terus mengakses halaman melalui protokol https, dengan kunci publik Diffie-Hellman yang singkat dan sementara di Chrome versi 45?

Memperbaiki peretasan untuk mengatasi masalah ini (Mac OSX)

• Jalankan ini dalam commandline untuk menyelesaikan masalah saat meluncurkan Chrome

Chrome:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Kenari:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Untuk Firefox

• Pergi ke about: config
• Cari security.ssl3.dhe_rsa_aes_128_shadansecurity.ssl3.dhe_rsa_aes_256_sha
• Atur keduanya untuk false.

CATATAN: Perbaikan secara permanen adalah memperbarui kunci DH dengan panjang> 1024

Memang, tampaknya bahwa browser telah mengambil serius masalah Diffie-Hellman dengan tombol yang lebih rendah dari 1024 panjangnya, yang sebagian adalah besar berita, tetapi di sisi lain, telah menghasilkan banyak pengguna Chrome marah .

Perbaikan untuk masalah ini (dan banyak lainnya yang terkait dengan keamanan) adalah tanggung jawab sysadmin, jadi seperti yang saya pahami, keputusan memblokir situs web apa pun yang menawarkan kunci Diffie-Hellman 512 bit yang lebih rendah atau lebih rendah adalah ukuran tekanan yang diarahkan ke orang yang mengelola keamanan di situs jarak jauh, dengan "sisi negatif" dari pengguna yang menderita efek tersebut.

Saat ini dimungkinkan untuk blacklist beberapa Suites Cipher ketika meluncurkan browser Google Chrome dengan menjalankannya dengan --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013parameter, yang tampaknya menonaktifkan yang terkait dengan kerentanan LogJam dan memungkinkan pengguna bergabung dengan situs, tetapi saya bersikeras bahwa itu harus menjadi tanggung jawab sysadmin. untuk memperbaiki masalah dengan kunci Diffie-Hellmann mereka.

Salah satu hal yang Anda tanyakan adalah apakah ada kerugian untuk menggunakan solusi yang tercantum (atau menggunakan orang lain yang tidak terdaftar) dalam pengaturan intranet. Jawaban singkatnya adalah selama server yang terlibat menggunakan kunci yang lemah, server yang terlibat akan rentan terhadap sistem apa pun yang menggunakan serangan logjam, dan tergantung pada sifat server, server kemudian dapat menjadi server yang dikompromikan yang dapat menyebarkan server masalah dengan klien lain yang mengakses server.

Dua skenario yang tidak mungkin adalah laptop yang telah terinfeksi dari intranet mengakses server internal ketika mereka terhubung ke intranet lagi, atau browser yang dikonfigurasi untuk mengabaikan masalah (seperti yang disarankan di atas dan di tempat lain) yang saat ini digunakan untuk mengakses internet dan yang kebetulan terhubung ke server yang dikompromikan menjadi titik awal untuk menyerang server intranet Anda.

Karena saya secara pribadi tidak terbiasa dengan semua masalah yang disajikan oleh kesalahan logjam, saya tidak bisa mengatakan apakah salah satu dari kedua situasi tersebut sangat mungkin. Pengalaman saya sendiri adalah bahwa sysadmin dengan server yang berhadapan dengan Internet cenderung untuk maju sejauh dari masalah yang mereka bisa. Yang mengatakan pengalaman saya juga bahwa admin server intranet cenderung melakukan hal-hal seperti membuat situs cantik sebelum menangani masalah keamanan server.

Menghadapi masalah yang sama. Jika Anda seorang pria di sisi server cukup tambahkan baris berikut di 443 konektor di server.xml kucing jantan

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" cipher = "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA"

Ini akan membantu Anda untuk menyelesaikan masalah kunci SSL ini.