Примушуйте Chrome ігнорувати "слабкий ефемерний відкритий ключ Діффі-Гелмана"

Оновлення Chrome на v45 блокує доступ до сторінок із слабкими публічними ключами Diffie-Hellman. Я розумію, що це пов'язано з Logjam. Я розумію, що перехід від https до http - це "рішення" в деяких випадках.

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

Очевидно, що рішенням було б, щоб захист міняв різні сервери інтрамережі, щоб бути захищеним від logjam, я розумію, що це, але це не варіант вже в цю хвилину, і я не можу більше працювати, поки це не буде виправлено. Оскільки це інтрамережа і просто підключення взагалі вимагає того, щоб бути фізично тут, ризик є незначним.

Чи є спосіб я продовжувати доступ до сторінок через протокол https зі слабкими ефемерними відкритими ключами Diffie-Hellman у Chrome версії 45?

Хокі вирішити цю проблему (Mac OSX)

• Запустіть це в командному рядку, щоб вирішити проблему під час запуску Chrome

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

• Перейдіть до про: config
• Шукати security.ssl3.dhe_rsa_aes_128_shaіsecurity.ssl3.dhe_rsa_aes_256_sha
• Встановіть їх обом false.

ПРИМІТКА. Постійно виправити було б оновлення ключа DH на довжину> 1024

Дійсно, браузери серйозно сприйняли проблему Diffie-Hellman із меншими клавішами довжиною 1024, що в частині є чудовою новиною, але, з іншого боку, це породило безліч розлючених користувачів Chrome .

Виправлення цієї проблеми (та багатьох інших, пов’язаних із безпекою) - це відповідальність систематичних службовців, тому, наскільки я розумію, рішення про блокування будь-якого веб-сайту, який пропонує слабкий 512-бітний або нижній ключ Diffie-Hellman, є мірою тиску, спрямованого на ті, хто керує безпекою на віддалених сайтах, за допомогою цьому наслідки "недолік" користувачів.

В даний час можна запустити в чорний список деякі Cipher Suites під час запуску браузера Google Chrome, запустивши його з --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013параметром, який, здається, відключить ті, які пов'язані з уразливістю LogJam і дозволяє користувачам приєднуватися до сайтів, але я наполягаю на тому, що це повинно бути відповідальним за систематизацію щоб вирішити проблему за допомогою ключів Diffie-Hellmann.

Однією з питань, про яку ви запитували, було те, чи є якісь недоліки у використанні перелічених обхідних шляхів (або використання інших, які не перераховані) в інтранетній установці. Коротка відповідь полягає в тому, що доки задіяні сервери використовують слабкі клавіші, залучені сервери будуть сприйнятливі до будь-якої системи, що використовує атаку 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.