Заставьте Chrome игнорировать «слабый эфемерный открытый ключ Диффи-Хеллмана»

Question

С обновлением Chrome до v45 он блокирует доступ к страницам со слабыми эфемерными открытыми ключами Диффи-Хеллмана. Я понимаю, что это связано с Logjam. Я понимаю, что в некоторых случаях переключение с https на http - это "решение".

Тем не менее, я не могу переключиться с https на http, потому что меня автоматически перенаправляет на https через веб-приложение, которое мы используем в нашей внутренней сети.

Очевидно, что решением было бы изменить безопасность различных серверов интрасети для защиты от logjam, я понимаю это, но это не вариант прямо сейчас, и я не могу больше выполнять работу, пока она не будет исправлена. Поскольку это интранет, а для простого подключения требуется физическое присутствие, риск минимален.

Можно ли как-нибудь продолжить доступ к страницам по протоколу https со слабыми эфемерными открытыми ключами Диффи-Хеллмана в Chrome версии 45?

Answer 1

Hacky исправить, чтобы обойти эту проблему (Mac OSX)

• Запустите это в командной строке, чтобы обойти проблему при запуске Chrome

Хром:

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

Канарейки:

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

Для Firefox

• Перейти к: конфигурации
• Ищите security.ssl3.dhe_rsa_aes_128_sha и security.ssl3.dhe_rsa_aes_256_sha
• Установите их обоих в false .

ПРИМЕЧАНИЕ: постоянное исправление будет означать обновление ключа DH длиной> 1024

Answer 2

Действительно, кажется, что браузеры всерьез восприняли проблему Диффи-Хеллмана с ключами длиной менее 1024, что отчасти является отличной новостью, но, с другой стороны, вызвало множество недовольных пользователей Chrome.

Решение этой проблемы (и многих других, связанных с безопасностью) является обязанностью системных администраторов, поэтому, насколько я понимаю, решение о блокировке любого веб-сайта, который предлагает слабый 512-битный или более низкий ключ Диффи-Хеллмана, является мерой давления, направленного на те , которые управляют безопасностью на удаленных объектах, с "нижней стороной" пользователей , страдающих от последствий.

В настоящее время существует возможность занести в черный список некоторые комплекты Cipher при запуске браузера Google Chrome, запустив его с параметром --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013 которые, похоже, отключают те, которые связаны с уязвимостью LogJam, и позволяют пользователям присоединяться к сайтам, но я настаиваю на том, что ответственность за устранение проблемы с ключами Диффи-Хеллманна должна быть у системных администраторов.

Answer 3

Одна из вещей, которые вы спросили, заключалась в том, было ли какое-либо неудобство при использовании перечисленных обходных путей (или при использовании других, не перечисленных) в настройках интрасети. Короткий ответ заключается в том, что, пока вовлеченные серверы используют слабые ключи, задействованные серверы будут восприимчивы к любой системе, использующей атаку с использованием logjam, и в зависимости от природы сервера сервер может впоследствии быть скомпрометированным сервером, который может распространять выдать другим клиентам доступ к серверу.

Два весьма вероятных сценария - это ноутбук, который был заражен из интрасети и получает доступ к внутреннему серверу при повторном подключении к интрасети, или браузер, настроенный на игнорирование проблемы (как предложено выше и в других местах), который в настоящее время используется для доступа в Интернет и который случается, подключается к скомпрометированному серверу, что является отправной точкой для атаки на серверы интрасети.

Поскольку я лично не знаком со всеми проблемами, возникающими в связи с ошибкой, я не могу сказать, является ли какая-либо из этих двух ситуаций особенно вероятной. Мой собственный опыт показывает, что системные администраторы, работающие с интернет-серверами, как можно быстрее опережают такие проблемы. Тем не менее, по моему опыту, администраторы серверов интрасети, как правило, делают что-то вроде создания сайтов, прежде чем решать проблемы безопасности сервера.

Answer 4

Столкнулся с такой же проблемой. Если вы серверная сторона, просто добавьте следующие строки в соединитель 443 в файле server.xml tomcat

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" шифры = "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"

Это поможет вам решить проблему с ключом SSL.