Як виправити вразливість 'logjam' у Apache (httpd)

Нещодавно була опублікована нова вразливість у Diffie-Hellman, неофіційно названа "logjam", для якої ця сторінка була складена, що пропонує запропонувати протидіяти вразливості:

У нас є три рекомендації щодо правильного розгортання Diffie-Hellman для TLS:

1. Вимкнути експорт пакетів шифрів Навіть незважаючи на те, що сучасні браузери більше не підтримують експортні набори, атаки FREAK та Logjam дозволяють зловмиснику підманювати браузери використовувати криптографію експортного класу, після чого TLS-з'єднання можна розшифрувати. Експортні шифри - це залишок політики 1990-х років, яка заважала експортувати сильні криптографічні протоколи із Сполучених Штатів. Жоден сучасний клієнт не покладається на експортні пакети, і в їх відключенні є невеликий недолік.
2. Розгортання (ефемерних) еліптично-кривих Diffie-Hellman (ECDHE). Обмін ключами Elliptic-Curve Diffie-Hellman (ECDH) дозволяє уникнути всіх відомих можливих криптоаналітичних атак, а сучасні веб-браузери тепер віддають перевагу ECDHE над початковим, кінцевим полем, Diffie-Hellman. Дискретні алгоритми журналу, які ми використовували для атаки на стандартні групи Diffie-Hellman, не отримують настільки сильної переваги від попередніх обчислень, а окремим серверам не потрібно генерувати унікальні еліптичні криві.
3. Створіть сильну, унікальну групу Diffie Hellman . Кілька фіксованих груп використовуються мільйонами серверів, що робить їх оптимальною ціллю для попередніх обчислень та потенційного підслуховування. Адміністратори повинні генерувати унікальні, 2048-бітні або сильніші групи Diffie-Hellman, використовуючи "безпечні" праймери для кожного веб-сайту чи сервера.

Які кроки найкращої практики я повинен вжити, щоб захистити свій сервер відповідно до вищезазначених рекомендацій?

З статті, яку ви пов’язали , є три рекомендовані кроки, щоб захистити себе від цієї вразливості. У принципі ці кроки стосуються будь-якого програмного забезпечення, яке ви можете використовувати з SSL / TLS, але тут ми розглянемо конкретні кроки щодо їх застосування до Apache (httpd), оскільки це саме програмне забезпечення.

1. Вимкнути експорт набір шифрів

Розглянемо зміни в конфігурації, які ми внесемо в нижченаведене (нижче !EXPORTв кінці SSLCipherSuiteрядка - як ми відключимо експорт набір шифрів)

2. Розгортання (ефемерне) еліптично-кривої Діффі-Гелмана (ECDHE)

Для цього вам необхідно змінити кілька параметрів в конфігураційних файлах Apache - а саме SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderщоб мати «передові методи» установку. Буде достатньо чогось наступного:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Примітка. Що стосується того, який SSLCipherSuiteпараметр слід використовувати, це завжди змінюється, і корисно звернутися до таких ресурсів, як цей, щоб перевірити наявність останньої рекомендованої конфігурації.

3. Створити сильну унікальну групу Діффі Хеллмана

Для цього можна запуститись

openssl dhparam -out dhparams.pem 2048.

Зауважте, що це спричинить значне навантаження на сервер під час генерації парам - ви завжди можете обійти цю потенційну проблему, генеруючи парами на іншій машині та використовуючи scpабо подібне для передачі їх на відповідний сервер для використання.

Щоб використовувати ці новогенеровані dhparamsв Apache, з документації Apache :

Для створення спеціальних параметрів DH використовуйте команду openssl dhparam. Крім того, ви можете додати наступні стандартні 1024-бітні параметри DH з RFC 2409, розділ 6.2, до відповідного файлу SSLCertificateFile :

(наголос мій)

після чого слід стандартний 1024-бітний параметр DH. З цього можна зробити висновок, що створені на замовлення параметри DH можуть бути просто додані до відповідних SSLCertificateFileпитань.

Для цього виконайте щось подібне до наступного:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Крім того, згідно з підрозділом Apache статті, з якою ви спочатку зв’язані, ви також можете вказати створений вами спеціальний файл dhparams, якщо ви не бажаєте змінювати сам файл сертифіката, таким чином:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

в будь-яких конфігураціях Apache, що стосуються вашої конкретної реалізації SSL / TLS - як правило, conf.d/ssl.confабо, conf.d/vhosts.confале це буде відрізнятися залежно від способу налаштування Apache.

Варто зазначити, що відповідно до цього посилання ,

Перед Apache 2.4.7 параметр DH завжди встановлюється на 1024 біт і не може бути налаштований користувачем. Це було зафіксовано в mod_ssl 2.4.7, що Red Hat підтримав у своєму розподілі RHEL 6 Apache 2.2 за допомогою httpd-2.2.15-32.el6

На Debian Wheezy оновлення apache2 до 2.2.22-13 + deb7u4 або пізнішої версії та openssl до 1.0.1e-2 + deb7u17. Вищезгаданий SSLCipherSuite не працює ідеально, замість цього використовуйте наступне в цьому блозі :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Ви повинні перевірити, чи ваша версія Apache пізніше цих номерів версій залежно від вашого розповсюдження, а якщо ні - оновіть її, якщо це можливо.

Після виконання вищезазначених кроків для оновлення конфігурації та перезапуску служби Apache для застосування змін слід перевірити, чи потрібна конфігурація, запустивши тести на SSLLabs та статтю, пов’язану з цією вразливістю.

На основі виправлення Вінні Ніссен я опублікував виправлення для Apache / 2.2.22 (Debian Wheezy, можливо, також можна використовувати на Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . для вашого відгуку.

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

Я повністю переключився. Врятувало мені багато часу на вирішення проблем щодо TLS, і - для наших конфігурацій - це також звільнило багато оперативної пам’яті за той же час. Насправді я знайшов використання nginx освіжаючим простим та простим, порівняно з безліччю ускладнень config httpd / apache, до яких я звик. Це може бути справою смаку, я до того, як я звернувся, досить вільно читав httpd / apache переписати / config / обслуговування, і це було легше, ніж я побоювався, що це буде. Існує відповідна недавня інформація про конфігурацію nginx, доступна в Інтернеті, і її база користувачів величезна, дуже активна та зручна для підтримки. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png