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

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

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

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

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

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

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

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

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

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

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

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

Столкнулся с такой же проблемой. Если вы парень на стороне сервера, просто добавьте следующие строки в соединитель 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.