Defaults.Exposed › Виправлення › Modern encryption (TLS version & ciphers)

Як виправити Modern encryption (TLS version & ciphers)

TLS — це замок, що шифрує дані між вашими відвідувачами і вашим сайтом. Дві речі роблять цей замок надійним: використання сучасної версії TLS (а не старих, зламаних) і використання сильних шифрів (фактичний рецепт шифрування). Ця сторінка охоплює обидва — а також кілька пов'язаних налаштувань, що не впливають на вашу оцінку, але варті уваги.

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

Що це може вам коштувати

• Клієнт платить або авторизується через готельний або кафе Wi-Fi; застаріле з'єднання або слабкий шифр дозволяє сторонньому в тій мережі прочитати його картку і пароль, і шахрайство — та розлючений дзвінок — простежується прямо до вашого сайту.
• Ви подаєте заявку на прийом карткових платежів (або ваш платіжний провайдер повторно перевіряє вас) і отримуєте відмову, тому що застаріле TLS або заборонений шифр порушує правила платіжної безпеки — ваша онлайн-каса заблокована до виправлення.
• IT-відділ великого клієнта проводить рутинне сканування безпеки перед підписанням, бачить, що ваш сайт все ще дозволяє зламане шифрування, і позначає вас як ризик — контракт зависає через проблему, що нічого не коштує виправити.
• На ваш стіл потрапляє скарга щодо захисту даних або витік, і перше запитання регуляторів — чи ви відповідно захищали дані клієнтів. Запуск шифрування, що публічно відомо як зламане протягом років, — дуже важка відповідь.
• Ваш сайт показує замок, тому всі вважають, що він повністю безпечний, і ця прогалина залишається непоміченою роками — поки один перехоплений логін або номер картки не перетворюється на інцидент, що коштує набагато дорожче, ніж безкоштовне виправлення.

Чому це важливо. Шифрування, що є безпечним, невидиме; шифрування, що застаріле або слабке, — це відповідальність, що тихо сидить до дня, коли воно коштує вам клієнта, контракту або проходження перевірки відповідності. Версія TLS і перевірки шифрів — це дві частини, що насправді рухають вашу оцінку, і обидві зазвичай є одним безкоштовним налаштуванням — немає жодних переваг у збереженні старих, зламаних варіантів увімкненими.

Простими словами

Коли хтось відвідує ваш сайт, все, що вони вводять — логіни, номери карток, імена, телефони, повідомлення — шифрується в дорозі, щоб сторонні не могли це прочитати. Технологія, що здійснює шифрування, називається TLS (ви також можете почути назву SSL — це її старіша назва). Щоб це шифрування насправді було безпечним, дві речі мають бути правильними:

1. Версія TLS — яке покоління технології ви використовуєте. Ранні версії (TLS 1.0 і 1.1) були публічно зламані роками; безпечні — TLS 1.2 і TLS 1.3.
2. Шифр — конкретний рецепт, що TLS використовує для шифрування. Деякі шифри (як RC4, DES і 3DES) були зламані і тепер заборонені; сучасні шифри все ще сильні.

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

Що це може коштувати вам

• Клієнта обікрали у публічному Wi-Fi. Хтось авторизується або платить з готелю, кафе або аеропорту. Оскільки ваш сайт все ще дозволяє стару версію TLS або слабкий шифр, сторонній у тій самій мережі примушує з’єднання знизитися до зламаного варіанту і читає їхній пароль і номер картки в реальному часі. Шахрайство падає на клієнта, але звинувачення — та дзвінок підтримки — падає на вас.
• Ваші карткові платежі відключають. Правила платіжної безпеки (PCI DSS) вимагають мінімум TLS 1.2 і явно забороняють слабкі шифри, як RC4. Коли ваш процесор повторно перевіряє вас або коли ви подаєте заявку на прийом карток, застаріла конфігурація провалює перевірку і ваша каса заблокована до виправлення — саме в найгірший момент для грошового потоку.
• Угода зависає при перевірці безпеки. Перед підписанням IT-відділ великого клієнта проводить рутинне сканування. Воно негайно позначає, що ваш сайт все ще приймає зламане шифрування — те саме, що виглядає як недбалість і змушує покупця цікавитися, що ще нещільно. Контракт знаходиться в підвішеному стані через проблему, що нічого не коштує виправити.
• Регулятор ставить незручне запитання. Після будь-якої скарги або витоку орган захисту даних першим хоче знати, чи ви відповідно захищали особисті дані. Запуск шифрування, що публічно відомо як зламане роками, дуже важко захистити.
• Воно ховається за замком роками. Оскільки ваш сайт все ще показує нормальний замок, ніхто не помічає прогалину — поки один перехоплений логін або номер картки не стає публічним інцидентом, що коштує набагато дорожче, ніж п’ятихвилинне виправлення могло б.

Що це насправді є

Версія TLS

Сайт не підтримує лише одну версію TLS — він може пропонувати кілька одночасно і дозволяти браузеру кожного відвідувача обирати. Сучасний відвідувач використовуватиме найновішу доступну версію і бачитиме нормальний замок. Небезпека в тому, що старі, зламані версії можуть сидіти поруч із хорошими як відкрений черевник: зловмисник може примусити з’єднання відвідувача «знизитись» до TLS 1.0 або 1.1, а потім використати відомі слабкості в цих версіях для розшифровки трафіку (атаки BEAST і POODLE — відомі приклади).

Як виглядає «добре» і як оцінюється:

• TLS 1.3 (з або без 1.2), без застарілих: найкращий результат — сучасна, чиста конфігурація. Повний бал.
• Лише TLS 1.2, без 1.3: безпечно і проходить, але ви залишаєте найновіше, найшвидше на столі.
• TLS 1.0 або 1.1 все ще приймаються: автоматична невдача, оцінено нулем і позначено як критичне — не має значення, що 1.2/1.3 також працюють, бо зламані версії є відкритим черевником.

Шифр

Після вибору версії TLS вибирає шифр — фактичний алгоритм, що шифрує дані. Більшість сучасних шифрів сильні. Кілька зламані і ніколи не повинні використовуватись: RC4 (його шифрування упереджене і витікає відкритий текст), DES (його ключ такий короткий, що може бути підібраний перебором), 3DES (вразливий до атаки «Sweet32»), а також NULL (без шифрування), EXPORT-grade (навмисно ослаблені) і анонімні шифри (без перевірки особи).

Наша перевірка шифрів робить дві речі. По-перше, дивиться на шифр, що ваш сервер фактично погодив з нами. По-друге — і це важлива частина — вона активно намагається встановити з’єднання, використовуючи кілька відомо зламаних шифрів (RC4, 3DES, EXPORT, NULL і анонімні варіанти). Сервер може вибирати сильний шифр при спілкуванні зі звичайним клієнтом, але все одно приймати слабкий, якщо зловмисник наполягає. Якщо ваш сервер приймає будь-який заборонений шифр, перевірка позначає це; прийняття критичного (як RC4 або NULL) — невдача.

Три інформаційні доповнення

Три пов’язані елементи повідомляються, але не впливають на вашу оцінку — вони позначені як інформаційні, бо не можуть бути надійно перевірені ззовні, і на будь-якому сучасному сервері або CDN вони вже правильно оброблені:

• TLS-компресія (атака CRIME): стара функція, що за замовчуванням вимкнена в кожному сучасному веб-сервері протягом більше десяти років.
• OCSP stapling: зручність для продуктивності і конфіденційності, де ваш сервер попередньо отримує підтвердження того, що його сертифікат не відкликаний. CDN, як Cloudflare, роблять це автоматично.
• Secure renegotiation: виправлення старої вразливості (CVE-2009-3555). TLS 1.3 повністю видалив перемовини, тому це вже не проблема, а сучасні сервери TLS 1.2 реалізують виправлення за замовчуванням.

Як це виправити (безкоштовно, ~30 хвилин)

Передайте це вашому IT-фахівцю — виправлення безкоштовне. Найпростіший надійний підхід — генерувати відому правильну конфігурацію, а не писати вручну: вставте тип вашого сервера в Mozilla SSL Configuration Generator за адресою https://ssl-config.mozilla.org/ і оберіть профіль «Intermediate» (широка сумісність) або «Modern» (лише TLS 1.3). Він виведе правильні рядки ssl_protocols і ssl_ciphers для вас.

За платформою:

1. Cloudflare або керований хост — зазвичай один або два кліки. В Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, і набори шифрів там керуються для вас. Більшість керованих хостів і конструкторів сайтів вже застосовують TLS 1.2+ з сильними шифрами.
2. Nginx. Встановіть лише сучасні версії і явний список сильних шифрів, потім перезавантажте:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

3. Apache. Вимкніть старі версії і закріпіть сильний список шифрів, потім перезапустіть:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Використовуйте безкоштовний інструмент IIS Crypto для вимкнення TLS 1.0 і 1.1, вимкнення RC4/DES/3DES/NULL/EXPORT шифрів і залишення TLS 1.2 і 1.3 із сильними шифрами. Шаблон «Best Practices» робить все це одним кліком.
5. Інформаційні доповнення (необов’язково, безкоштовно). Якщо хочете повне очищення: в Nginx додайте ssl_stapling on; ssl_stapling_verify on; для OCSP stapling; в Apache — SSLUseStapling On. TLS-компресія і secure renegotiation вже за замовчуванням безпечні на сучасних серверах.
6. Перевірте, потім повторно перевірте тут. Підтвердіть, що залишаються лише безпечні версії і шифри, потім повторно запустіть цю перевірку. Де можливо, увімкніть TLS 1.3 поряд з 1.2: він і швидший, і безпечніший.

Поширені помилки

• «У нас є замок, тому ми в безпеці». Замок лише підтверджує, що захищене з’єднання існує. Він нічого не говорить про те, чи стара версія або заборонений шифр все ще приймаються у фоні.
• Виправляти версію, але не шифри (або навпаки). Вимкнення TLS 1.0/1.1 не прибирає автоматично RC4 або 3DES, а закріплення сильних шифрів не вимикає автоматично старих версій. Встановлюйте обидва — згенерована конфігурація вище робить це.
• Залишати ввімкненими «legacy» або перемикачі «сумісності зі старими браузерами». Багато хостів і CDN мають параметр, що тихо повторно вмикає зламані версії або слабкі шифри «для сумісності». Це майже ніколи не допомагає реальному відвідувачу і безпосередньо викликає це виявлення.
• Забувати фактично перезавантажити/перезапустити сервер. Зміни конфігурації не набирають чинності, поки веб-сервер не буде перезавантажено.
• Налаштовувати один сервер, але не всі. Якщо ви запускаєте балансувальник навантаження, кілька веб-серверів або окремі поддомени, кожна TLS-кінцева точка потребує тієї ж конфігурації.

Що запам’ятати

Версія TLS і шифр — це дві частини вашого шифрування, що насправді рухають вашу оцінку, і обидві зводяться до вимкнення параметрів, що публічно зламані роками. Виправлення безкоштовне, зазвичай це один сучасний рядок конфігурації на сервер, і для звичайного відвідувача нічого не змінює, окрім того, що їхнє з’єднання стає справді безпечним. Пов’язані елементи — компресія, OCSP stapling, secure renegotiation — варті знання, але не вплинуть на вашу оцінку, і на будь-якому сучасному налаштуванні вони вже обробляються для вас.

FAQ