Chrome'u "zayıf geçici Diffie-Hellman genel anahtarını” görmezden gelmeye zorla


17

Chrome'un v45'e güncellenmesiyle, zayıf efermeral Diffie-Hellman genel anahtarlarına sahip sayfalara erişimi engelliyor. Bunun Logjam'dan kaynaklandığını anlıyorum. Https'den http'ye geçişin bazı durumlarda "çözüm" olduğunu anlıyorum.

Ancak, intranetimizde kullandığımız web tabanlı yazılım tarafından otomatik olarak https'ye yönlendirildiğim için https'den http'ye geçemiyorum.

Açıkçası, çözüm, çeşitli intranet sunucularının güvenliğini logjam'dan korumak için değiştirecekti, anlıyorum, ancak bu şu anda bir seçenek değil ve düzeltilinceye kadar daha fazla iş yapamam. Bu bir intranet olduğundan ve basitçe bağlanmak birinin fiziksel olarak burada olmasını gerektirdiğinden, risk çok küçüktür.

Chrome sürüm 45'te zayıf geçici Diffie-Hellman genel anahtarlarıyla https protokolü aracılığıyla sayfalara erişmeye devam edebilmemin bir yolu var mı?


Başına: productforums.google.com/forum/#!topic/chrome/xAMNtyxfoYM bu soruna geçici bir çözüm bulmak için tek tek şifre takımlarını devre dışı bırakmak mümkün görünüyor. Açık olanın dışında (güvenliğinizi azaltmak dış ağlardaki risklerinizi artırır), bunu bir intranette kullanmanın herhangi bir dezavantajı var mı? Ve daha fazla bilgi için: fehlis.blogspot.com/2013/12/… code.google.com/p/chromium/issues/detail?id=58833
Raine Dragon

Yanıtlar:


8

Bu sorunu aşmak için haksız düzeltme (Mac OSX)

  • Chrome'u başlatırken sorunu çözmek için bunu komut satırında çalıştırın

Krom:

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

Kanarya:

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

Firefox için

  • Şuraya git: config
  • Arama security.ssl3.dhe_rsa_aes_128_shavesecurity.ssl3.dhe_rsa_aes_256_sha
  • İkisini de olarak ayarlayın false.

NOT: Kalıcı düzeltme DH anahtarını> 1024 uzunluğunda güncellemek olacaktır


5

Gerçekten de, tarayıcıların 1024'ten daha düşük anahtarlarla Diffie-Hellman sorununu ciddiye aldıkları anlaşılıyor, bu da bir kısım harika bir haber, ancak öte yandan çok sayıda kızgın Chrome kullanıcısı oluşturdu .

Bu sorunun düzeltilmesi (ve güvenlikle ilgili diğer birçokları) sistem yöneticilerinin sorumluluğundadır, bu yüzden anladığım kadarıyla, zayıf bir 512 bit veya daha düşük Diffie-Hellman anahtarı sunan herhangi bir web sitesini engelleme kararı, uzak sitelerde güvenliği yönetenler , etkilenen kullanıcıların "olumsuz" etkisi.

Şu anda, Google Chrome tarayıcısını --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013LogJam güvenlik açığıyla ilgili olanları devre dışı bırakan ve kullanıcıların sitelere katılmasına izin veren parametre ile çalıştırarak bazı Cipher Suites'leri kara listeye almak mümkündür , ancak sistem yöneticilerinin sorumluluğu olması gerektiğinde ısrar ediyorum sorunu Diffie-Hellmann'ın anahtarlarıyla düzeltmek için.


Teşekkür ederim nKn, Chrome 45 sürümüne güncellendiği için Cisco Finesse ile bir cazibe gibi çalıştı ... ve şimdi programa erişemedim.
Christopher Chipps

0

Sorduğunuz şeylerden biri, bir intranet kurulumunda listelenen geçici çözümlerin (veya listelenmeyen başkalarının kullanılması) herhangi bir dezavantaj olup olmadığıydı. Kısa cevap, ilgili sunucular zayıf anahtarlar kullandıkları sürece, ilgili sunucuların bir günlük saldırı saldırısı kullanan herhangi bir sisteme duyarlı olacağı ve sunucunun doğasına bağlı olarak sunucunun, daha sonra, sunucuya erişen diğer istemciler için sorun.

Muhtemel olmayan iki senaryo, intranete tekrar bağlandıklarında dahili sunucuya erişen intranetten enfekte olmuş bir dizüstü bilgisayar veya şu anda internete erişmek için kullanılan ve yukarıda (başka bir yerde önerildiği gibi) sorunu göz ardı edecek şekilde yapılandırılmış bir tarayıcıdır. intranet sunucularınıza saldırmak için bir atlama noktası olan güvenliği ihlal edilmiş bir sunucuya bağlanır.

Logjam kusurunun sunduğu tüm konulara şahsen aşina olmadığım için, bu iki durumdan herhangi birinin özellikle muhtemel olup olmadığını söyleyemem. Kendi deneyimim, Internet'e bakan sunuculara sahip sistem yöneticilerinin olabildiğince çok sorun yaşama eğiliminde olmalarıdır. Bu da benim tecrübelerimin, intranet sunucusu yöneticilerinin sunucu güvenliği sorunlarını ele almadan önce siteler yapma gibi şeyler yapma eğiliminde olduğunu söyledi.


0

Aynı sorunla karşı karşıya. Sunucu tarafı iseniz, server.xml tomcat içindeki 443 bağlayıcısına aşağıdaki satırları ekleyin

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" şifrelere = "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"

Bu, bu SSL anahtarı sorununu çözmenize yardımcı olacaktır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.