Ця інструкція розкриє, як налаштувати високий рівень безпеки SSL на веб-сервері Nginx. Ми зробимо це шляхом поновлення OpenSSL до останньої версії, щоб знизити небезпеку таких атак, як Heartbleed, відключення SSL стиснення і експорту шифру для пом'якшення таких типів атак, як FREAK, CRIME і LogJAM, відключення SSLv3 і нижче через уразливість в протоколі, створимо потужний кріптоключа дозволяє застосувати шифрування, коли це можливо. Ми також включимо HSTS і HPKP. Таким чином, ми отримаємо потужну і професійну конфігурацію SSL, а також отримуємо найвищий клас A + в Qually Labs SSL Test.
Ми збираємося змінити налаштування Nginx в файлі /etc/nginx/sited-enabled/yoursite.com (на Ubuntu / Debian) або в /etc/nginx/conf.d/nginx.conf (на RHEL / CentOS).
Вам необхідно відредагувати частини між блоком сервера в конфігурації сервера для 443 порту (ssl config). В кінці інструкції ви зможете знайти приклад повної конфігурації.
Переконайтеся, що ви створили резервні копії файлів перед їх редагуванням!
BEAST атаки і RC4
Коротше кажучи, шляхом злому CBC алгоритму шифрування в - блок шифрування ланцюжком - режимах, частини зашифрованого трафіку можуть бути таємно розшифровані.
Відключення RC4 має ряд наслідків
- По-перше, користувачі з древніми браузерами, такими як Internet Explorer на Windows XP будуть використовувати альтернативу - 3DES. Triple-DES є більш безпечним, ніж RC4, але це значно дорога операція. Ваш сервер буде оплачувати процесорний час для цих користувачів.
- По-друге, RC4 пом'якшує BEAST. Таким чином, відключення RC4 робить користувачів TLS 1.0, сприйнятливими до цієї атаки, переміщаючи їх AES-CBC (звичайне "виправлення" BEAST з серверної сторони на підвищений пріоритет RC4).
Існує впевненість, що недоліки в RC4 значно переважують ризики, пов'язані з BEAST. Дійсно, зі зменшенням на стороні клієнта (яке забезпечують обидва Chrome і Firefox), BEAST не є проблемою. Але ризик від RC4 тільки набирає обертів: Докладний криптоаналіз спливе на поверхню найближчим часом.
Факторинг RSA-EXPORT Ключів [Factoring RSA-EXPORT Keys (FREAK)]
FREAK є вразливістю людина-в-середині [man-in-the-middle (MITM)], виявлення групою криптографов INRIA, Microsoft Research і IMDEA. FREAK означає "Фактор RSA-Експорту Ключів"
Виявляється, що деякі сучасні TLS клієнти - в тому числі SecureTransport від Apple і OpenSSL - містять помилку. Ця помилка змушує їх приймати ключі RSA експорт-класу, навіть якщо клієнт не запитав експорт-клас RSA. Наслідки цієї помилки можуть бути досить жалюгідними: вона допускає атаки "людина в середині" в результаті чого, активний зловмисник може змусити погіршити якість з'єднання, за умови, що клієнт є вразливим і сервер підтримує експорт RSA.
Є два типи атаки, при якій сервер повинен також прийняти "експорт клас RSA".
Атака MITM працює наступним чином
- У Hello повідомленні клієнта, він запитує стандартний 'RSA' набір шифрів.
- MITM зловмисник змінює це повідомлення, щоб запросити 'export RSA'.
- Сервер відповідає 512-бітовим ключем RSA експорту, підписаного його довгостроковим ключем.
- Клієнт приймає цей слабкий ключ через помилку OpenSSL / SecureTransport.
- Атакуючий фактор RSA модуля, відновлює відповідний ключ дешифрування RSA.
- Коли клієнт шифрує 'pre-master secret' сервера, зловмисник тепер може його розшифрувати, щоб відновити TLS 'master secret'.
- З цього моменту, зловмисник бачить відкритий текст і може вводити все, що хоче.
Набір шифрів, запропонований на цій сторінці не дає можливості використання шифрів експорт класу. Переконайтеся, що ваш OpenSSL оновлений до останньої доступної версії і закликайте своїх клієнтів також використовувати оновлене програмне забезпечення.
Затор (ДХ ЕКСПОРТ) [Logjam (DH EXPORT)]
Дослідники з декількох університетів і інститутів провели дослідження, яке показало проблему в протоколі TLS. У доповіді дослідники вказують на два методи атаки.
Вирішуючи обмін ключами Діффі-Хеллмана [Diffie-Hellman], які використовують TLS для узгодження загального ключа і ведуть узгодження безпечного з'єднання через звичайне текстове з'єднання.
Друга загроза в тому, що багато серверів і використовують одні й ті ж прості числа для Діффі-Хеллмана обміну ключами, замість створення своїх власних унікальних DH параметрів.
Група вважає, що академічна команда може розірвати 768-розрядні прості числа, і, що державні агентства можуть розірвати 1024-бітове просте число. Порушивши одне 1024-бітове просте число, можна підслухати 18 відсотків з одного мільйона топових доменів HTTPS. Злом другого числа відкриє 66 відсотків віртуальних приватних мереж і 26 відсотків SSH серверів.
Пізніше, в цьому керівництві, ми створимо наші власні параметри унікальних DH і ми використовуємо метод шифрування, який заборонить Експорт класу шифрів. Переконайтеся, що ваш OpenSSL оновлений до останньої доступної версії і закликайте своїх клієнтів також використовувати свіже програмне забезпечення. Оновлені браузери відмовляються приймати DH параметри нижче 768/1024 біт після цього виправлення.
На Cloudflare є докладний посібник з атакам типу Затор (ДХ ЕКСПОРТ) [Logjam (DH EXPORT)].
Частотоотбор (Heartbleed)
У результатах перевірки правильності введення (через відсутність перевірки кордонів) в реалізації частотоотбора DTLS розширення (RFC6520), таким чином, назва "бага" походить від "частотоотбор" ( "heartbeat"). Уразливість класифікується як більш читабельним буфером, ситуацією можливості читання більшої кількості даних, ніж повинно бути дозволено.
Які версії OpenSSL страждають від Частотоотбор (Heartbleed)?
Статус різних версій:
- OpenSSL 1.0.1 по 1.0.1f (включно) уразливі
- OpenSSL 1.0.1g НЕ вразлива
- OpenSSL 1.0.0 гілка НЕ вразлива
- OpenSSL 0.9.8 гілка НЕ вразлива
При оновленні OpenSSL ви ставали не уразливі для цієї помилки.
SSL Стиснення (CRIME атака)
CRIME атака використовує SSL Стиснення щоб творити свою справу. SSL стиснення за замовчуванням вимкнено в Nginx 1.1.6 + / 1.0.9 + (якщо використовується OpenSSL 1.0.0+) і Nginx 1.3.2 + / 1.2.2 + (якщо використовуються більш старі версії OpenSSL).
Якщо ви використовуєте ще більш ранню версію Nginx або OpenSSL і ваш збірки не можна портував цю опцію, то вам потрібно перекомпілювати OpenSSL без підтримки ZLIB. Це дозволить відключити використання в OpenSSL методу стиснення DEFLATE. Якщо ви зробите це, то ви можете використовувати регулярний метод стиснення HTML DEFLATE.
SSLv2 і SSLv3
SSL v2 є небезпечним, тому нам потрібно вивести його з ладу. Ми також відключимо SSLv3, як і TLS 1.0, що страждає від атак на застарілі версії, який дозволяє зловмисникові змусити з'єднання використовувати SSLv3 і через нього відключити безпечне з'єднання.
Знову ж відредагуйте в файлі конфігурації:
Підробка і TLS-FALLBACK-SCSV
SSLv3 дозволяє експлуатувати помилку підроблення (POODLE). Це ще одна з головних причин для відключення цієї функції.
Google запропоновано розширення SSL / TLS іменоване TLSFALLBACKSCSV, яке прагне запобігти примусове відключення SSL.
Чи включається автоматично при оновленні OpenSSL до наступних версій:
- OpenSSL 1.0.1 має TLSFALLBACKSCSV в 1.0.1j і вище
- OpenSSL 1.0.0 має TLSFALLBACKSCSV в 1.0.0o і вище
- OpenSSL 0.9.8 має TLSFALLBACKSCSV в 0.9.8zc і вище
Більш детальна інформація в документації NGINX.
шифрування Люкс
Примус секретність забезпечує цілісність ключа сеансу в тому випадку, якщо буде скомпрометований довгостроковий ключ. PFS вирішує цю задачу шляхом застосування виведення нового ключа для кожного сеансу.
Це означає, що, коли секретний ключ потрапляє під загрозу він не може бути використаний для розшифровки записаного SSL трафіку.
З шифрів, які забезпечують ідеальне Примус секретність ті, які використовують ефемерну форму обміну ключами Діффі-Хеллмана. Недоліком є їх накладні витрати, які можуть бути поліпшені за допомогою еліптичних кривих варіантів.
Рекомендовані наступні два набору шифрів, і деякі від Mozilla Foundation.
Рекомендований метод шифрування:
Рекомендований метод шифрування для забезпечення зворотної сумісності (IE6 / WinXP):
Якщо ваша версія OpenSSL застаріла, недоступні шифри будуть відкинуті автоматично. Завжди використовуйте повний набір методів шифрування вище, і, нехай OpenSSL вибере ті, які він підтримує.
Упорядкування методів шифрування дуже важливо, оскільки воно вирішує, які алгоритми будуть обрані в пріоритетному порядку. Рекомендовані вище алгоритми, вказані з пріоритетом забезпечує ідеальну ступінь безпеки.
Більш старі версії OpenSSL не може повертати повний список алгоритмів. AES-GCM і деякі ECDHE з'явилися порівняно недавно, і, відсутні в більшості версій OpenSSL, що поставляються з Ubuntu або RHEL.
логіка приоритизации
ECDHE + AESGCM шифри вибираються в першу чергу. Це TLS 1.2 шифри. Жодна з відомих в даний час атак не спрямована на ці шифри.
PFS шіфрометоди є кращими, з ECDHE перші, а потім DHE.
AES 128 переважніше AES 256. Було багато дискусій про те, чи варті накладні витрати AES256 додаткової безпеки далеко не очевидного результату. На даний момент AES128 є кращим, оскільки він забезпечує хорошу безпеку, дуже швидкий, і, здається, більш стійким до тимчасових атакам.
Для забезпечення зворотної сумісності шіфрометода, AES краще 3DES. BEAST атаки на AES пом'якшуються в TLS 1.1 і вище, чого важко досягти в TLS 1.0. В не назад сумісному шіфрометоде, 3DES немає.
RC4 видаляється повністю. 3DES використовується для забезпечення зворотної сумісності. Дивіться обговорення в # RC4_weaknesses.
обов'язкові скиди
- aNULL містить не пройшли перевірку автентичності обміну ключами Діффі-Хеллмана, які є об'єктом атак Людина-В-Середині [Man-In-The-Middle (MITM)]
- eNULL містить шифри нуль-шифрування (у відкритому вигляді)
- EXPORT успадковані слабкі шифри, які були відзначені як експортований законодавством США
- RC4 містить шифри, які використовують застарілий алгоритм ARCFOUR
- DES містить шифри, які використовують застарілий стандарт шифрування даних
- SSLv2 містить всі шифри, які були визначені в старій версії стандарту SSL, тепер не рекомендується
- MD5 містить всі шифри, які використовують застаріле дайджест повідомлення 5 в якості алгоритму хешування
Додаткові налаштування
Переконайтеся, що ви також додали ці рядки:
При виборі шифру під час SSLv3 або TLSv1 рукостискання, як правило, використовується перевагу клієнта. Якщо ця директива включена, то пріоритетно буде використано перевагу сервера.
Примусова Секретність і Ефемерні Параметри Діффі Хеллмана
Концепція примусу секретності проста: клієнт і сервер домовляються про ключ, який ніколи не потрапляє в передачу, і, руйнується в кінці сесії. Приватний RSA від сервера використовується для підпису обміну ключами Діффі-Хеллмана між клієнтом і сервером. Попередній майстер-ключ, отриманий з квітірованія (рукостискання) Діффі-Хеллмана, потім використовується для шифрування. Оскільки, попередній майстер-ключ є специфічним для з'єднання між клієнтом і сервером, і використовується тільки протягом обмеженого періоду часу, воно називається ефемерним.
З Примусової секретні, якщо зловмисник опановує приватним ключем сервера, він не зможе розшифрувати минулі зв'язки. Приватний (закритий) ключ використовується тільки для підписання DH рукостискання, яке не розкриває попередній майстер-ключ. Діффі-Хеллмана гарантує, що попередні майстер-ключі ніколи не залишають клієнт і сервер, і, не можуть бути перехоплені MITM.
Всі версії Nginx починаючи з 1.4.4 спираються на OpenSSL для вхідних параметрів Діффі-Хеллмана (DH) [Diffie-Hellman (DH)]. На жаль, це означає, що Ефемерність Діффі-Хеллмана (DHE) буде використовувати за замовчуванням OpenSSL, які включають 1024-бітний ключ для обміну ключами. Так, як ми використовуємо 2048-бітний сертифікат, DHE клієнти будуть використовувати слабший обмін ключами, чому не ефемерні DH клієнти.
Нам необхідно сформувати більш стійкий DHE параметр:
А потім змусити Nginx використовувати його для DHE обміну ключами:
OCSP Скріплення [OCSP Stapling]
При підключенні до сервера, клієнти повинні перевірити достовірність сертифіката сервера, використовуючи або Список Відкликання Сертифіката (CRL) [Certificate Revocation List (CRL)], або Підтримку Протоколу Стану Сертифікату (OCSP) [Online Certificate Status Protocol (OCSP)] запис. Проблема в тому, що CRL списки виросли до величезних розмірів і не завжди доступні для завантаження.
OCSP набагато більш легковагий так, як тільки один запис витягується одночасно. Але побічний ефект полягає в тому, що OCSP запити повинні бути зроблені на 3-й частині OCSP відповідачем при підключенні до сервера, до чого додаються затримки і можливі збої. Насправді, OCSP відповідачі, які використовуються ЦС (CA), часто настільки ненадійні, що браузер буде терпіти невдачу за часом, якщо відповідь не буде отримана своєчасно. Це знижує безпеку, дозволяючи зловмисникові використовувати DoS на OCSP відповідач, щоб відключити перевірку.
Рішення полягає в тому, щоб дозволити серверу посилати кешовану OCSP запис під час рукостискання TLS, тому обходячи OCSP відповідач. Цей механізм дозволяє заощадити на запитах туди і назад між клієнтом і OCSP відповідачем, і називається OCSP Скріплення [OCSP Stapling].
Сервер посилає кешированний відповідь OCSP тільки якщо клієнт запитує його, оголосивши підтримку status_request TLS розширення в запиті CLIENT HELLO.
Більшість серверів буде кешувати відповідь OCSP на термін до 48 годин. Через рівні проміжки часу, сервер буде підключатися до OCSP відповідача ЦС (Центр Сертифікації) (CA), щоб отримати свіжу запис OCSP. Розташування OCSP відповідача береться з поля Інформації Повноважень Доступу [Authority Information Access] підписаного сертифіката.
HTTP Strict Transport Security
Коли це можливо, слід включити HTTP Strict Transport Security (HSTS) який вказує браузерам спілкуватися з вашим сайтом тільки через HTTPS.
HTTP Public Key Pinning Extension
Ви повинні також включити HTTP Public Key Pinning Extension.
Public Key Pinning означає, що ланцюжок сертифікатів повинна включати в себе відкритий ключ з білого списку. Це гарантує, що тільки білий список Центрів Сертифікації (ЦС) [whitelisted Certificate Authorities (CA)] може підписувати сертифікати для * .example.com, а не який-небудь ЦС їх зберігається вашим браузером.
Якщо ви застосували вищевказані рядки конфігурації необхідно перезапустити nginx:
# Спершу перевірте конфігурацію:
# Потім перезавантажте:
Тепер використовуйте тест SSL Labs, щоб побачити як ви отримаєте високий A клас. І, звичайно ж, впевненість безпеки, стійкості і доказ професійної конфігурації SSL!