Defaults.Exposed › Поправки › Съвременно криптиране (TLS версия и шифри)

Как да поправите Съвременно криптиране (TLS версия и шифри)

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

Заключение за вашия бизнес: Ако вашият сайт работи с остаряло криптиране или слаби шифри, личните данни, въвеждани от клиентите ви — входови данни, номера на карти, информация за контакт — могат да бъдат тихо прихванати и прочетени в споделени мрежи, и може да не преминете проверките за сигурност, изисквани от банки, доставчици на плащания и по-големи клиенти преди да правят бизнес с вас.

Какво може да ви струва това

• Клиент плаща или влиза в сметката си в хотелски или кафе WiFi, остаряла връзка или слаб шифър позволяват на непознат в тази мрежа да прочете картата и паролата им в реално време, а измамата — и разгневеното обаждане — проследявате директно до вашия сайт.
• Кандидатствате да приемате плащания с карта (или доставчикът ви на плащания ви одитира повторно) и получавате отказ, защото остарял TLS или забранен шифър нарушава правилата за сигурност на плащанията — онлайн плащането ви е замразено, докато не се поправи.
• IT екипът на по-голям клиент прави рутинно сканиране за сигурност преди подписване, вижда, че сайтът ви все още позволява повредено криптиране и ви маркира като риск — договорът спира заради проблем, за чието поправяне не се плаща нищо.
• Жалба или пробив в защитата на данните попадат на масата ви и първото нещо, което регулаторите питат, е дали сте защитили клиентски данни 'по подходящ начин' — използването на криптиране, публично известно като повредено от години, е много трудно да се защити.
• Сайтът ви показва катинар, така че всеки приема, че е напълно безопасен, и тази пропаст остава незабелязана с години — докато едно прихванато влизане или номер на карта стане инцидент, много по-скъп от безплатната поправка.

Защо има значение. Безопасното криптиране е невидимо; остарялото или слабото е отговорност, седяща тихо, докато денят дойде, когато ви струва клиент, договор или спазване на изискванията. Проверките на TLS версията и шифрите са двете части, реално движещи вашата оценка, и двете обикновено са единична безплатна настройка — няма ничакъв ъпсайд в оставянето на старите, повредени опции включени.

С прости думи

Когато някой посещава вашия уебсайт, всичко, което въвеждат — входови данни, номера на карти, имена, телефонни номера, съобщения — се скремблира при транзит, за да не могат непознати да го четат. Технологията, извършваща скремблирането, се казва TLS (може да го чуете и с по-старото му название SSL). За да бъде реално безопасно скремблирането, трябва да са правилни две неща:

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

Тази страница обхваща и двете, защото сайт може да получи едното правилно, а другото погрешно. Можете да имате съвременна ключалка со стара, кракаема рецепта все още включена — или силна рецепта, защитена от остаряла ключалка. Всяка пропаст е отворена врата. И двете обикновено се затварят от същата единична безплатна промяна на настройките на вашия сървър или хостинг.

Какво може да ви струва това

• Клиент е ограбен на публичен WiFi. Някой влиза в сметката си или плаща от хотел, кафе или летище. Тъй като сайтът ви все още позволява стара TLS версия или слаб шифър, непознат в същата мрежа принудително сваля връзката до кракаемата опция и чете паролата и номера на картата им в реално време. Измамата е върху клиента, но обвинението — и обаждането за поддръжка — е върху вас.
• Плащанията с карта се изключват. Правилата за сигурност на плащанията (PCI DSS) изискват TLS 1.2 като минимум и изрично забраняват слаби шифри като RC4. Когато процесорът ви одитира повторно или когато кандидатствате да приемате карти, остаряла конфигурация не преминава проверката и плащанията ви са замразени, докато не се поправи — точно в неподходящия момент за паричния поток.
• Сделка спира при проверка за сигурност. Преди по-голям клиент да подпише, IT екипът им прави рутинно сканиране. То незабавно открива, че сайтът ви все още приема повредено криптиране — вида находка, изглеждаща небрежна и карайки купувача да се чуди какво друго е разхлабено. Договорът стои в лимбо заради проблем, за чието поправяне не се плаща нищо.
• Регулатор задава неудобния въпрос. След всяка жалба или пробив, първото нещо, което орган за защита на данните иска да знае, е дали сте защитили лични данни „по подходящ начин.” Използването на криптиране, публично известно като повредено от години, е много трудно да се защити и „не сме осъзнавали, че старата версия е все още включена” е неудобен отговор.
• Скрива се зад катинара с години. Тъй като сайтът ви все още показва нормален катинар, никой не забелязва пропастта — докато едно прихванато влизане или номер на карта стане публичен инцидент, много по-скъп от петминутната поправка.

Какво всъщност е

TLS версията

Сайт не само поддържа една версия на TLS — може да предлага едновременно няколко и да позволи на браузъра на всеки посетител да избере. Съвременен посетител ще използва най-новата налична версия и ще види нормален катинар. Опасността е, че старите, повредени версии могат да седят там наред с добрите като отворена задна врата: нападател може да принуди връзката на посетителя да „деградира” до TLS 1.0 или 1.1 и след това да използва известните слабости в тези версии (атаките BEAST и POODLE са прочутите примери), за да декриптира трафика.

Така нашата проверка се свързва с вашия сайт и тества всяка версия поотделно — TLS 1.0, 1.1, 1.2 и 1.3 — за да види кои вашият сървър все още приема. Ето как изглежда „добро” и как се оценява:

• TLS 1.3 (с или без 1.2) и без legacy: най-добрият резултат — съвременна, чиста конфигурация. Пълни точки.
• Само TLS 1.2, без 1.3: безопасно и преминава, но пропускате най-новата, най-бърза версия. Повечето точки; активирането на 1.3 си заслужава.
• TLS 1.0 или 1.1 все още приет: автоматичен провал, оценен нула и маркиран като критичен — без значение, че 1.2/1.3 също работят, тъй като повредените версии са отворената врата. Това е, което трябва да поправите.

Шифърът

След като е избрана версия, TLS избира шифър — реалния алгоритъм, скремблиращ данните. Повечето съвременни шифри са силни. Шепа са повредени и никога не трябва да се използват: RC4 (скремблирането му е изкривено и изтича обикновен текст), DES (ключът му е толкова кратък, че може да бъде brute-forced), 3DES (уязвим на атаката „Sweet32”), плюс NULL (без криптиране изобщо), EXPORT-grade шифри (умишлено отслабени — атаките FREAK и Logjam) и анонимни шифри (без проверка на самоличността, така че имитатор може да седи по средата).

Нашата проверка за шифри прави две неща. Първо, разглежда шифъра, реално договорен от вашия сървър с нас. После — и тази е важната part — активно опитва handshake с няколко известни повредени шифра (RC4, 3DES, EXPORT, NULL и анонимни варианти). Сървър може да избере силен шифър при разговор с модерен клиент, но все още да приема слаб, ако нападателят настоява — и това е реален риск от деградиране. Ако вашият сървър приема забранен шифър, проверката го маркира; приемането на критичен (като RC4 или NULL) е провал. (При TLS 1.3 тук няма от какво да се притеснявате — тази версия е премахнала всеки слаб шифър по дизайн, така че пробите се пропускат.)

Трите информационни допълнения

Три свързани елемента се докладват, но не засягат вашата оценка — маркирани са като информационни, тъй като не могат да бъдат надеждно проверени отвън и при всеки съвременен сървър или CDN вече се обработват правилно:

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

Ние извеждаме тях, за да има пълна картина вашия IT специалист, но за огромното мнозинство от собственици няма нищо за правене — вашата оценка се определя от проверките на версиите и шифрите по-горе.

Как да го поправите (безплатно, ~30 минути)

Предайте това на вашия IT специалист — поправката е безплатна. Този раздел е за когото управлява вашия домейн, уебсайт или хостинг. Поправката е конфигурационна промяна, не покупка; ние таксуваме само за мониторинг, че криптирането ви остава правилно конфигурирано с течение на времето. Единствената съвременна конфигурация по-долу поправя и проблема с версията, и проблема с шифъра наведнъж.

Най-простият надежден подход е да генерирате известна добра конфигурация, вместо да пишете ръчно: поставете типа на вашия сървър в Mozilla’s 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 и наборите от шифри там се управляват за вас (платформата няма да предложи забранени шифри). Повечето управлявани хостове и конструктори на сайтове (Squarespace, Wix, Shopify, съвременни WordPress хостове) вече прилагат TLS 1.2+ с силни шифри — просто потвърдете, че няма „legacy TLS” или опция „old-browser compatibility” все още включена.
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;
   

   (TLS 1.3 изисква OpenSSL 1.1.1+ на машината.)
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; (с ред resolver) за OCSP stapling; в Apache, SSLUseStapling On. TLS компресията и secure renegotiation вече са безопасни по подразбиране на съвременни сървъри — не е нужно действие. В Cloudflare и трите се обработват автоматично.
6. Проверете, след това проверете повторно тук. Потвърдете, че остават само безопасните версии и шифри — например с nmap --script ssl-enum-ciphers -p 443 yourdomain.com или тествайте на свързаните инструменти на https://ssl-config.mozilla.org/ — след което стартирайте тази проверка отново. Където е възможно, активирайте TLS 1.3 наред с 1.2: той е и по-бърз, и по-сигурен.

Чести грешки

• „Имаме катинар, значи сме наред.” Катинарът само доказва, че съществува сигурна връзка. Не казва нищо за това дали старата версия или забранен шифър все още се приемат на фона — именно тази пропаст намират тези проверки.
• Поправяне на версията, но не и шифрите (или обратното). Деактивирането на TLS 1.0/1.1 не премахва автоматично RC4 или 3DES, а закачването на силни шифри не деактивира автоматично старите версии. Задайте и двете — генерираната конфигурация по-горе го прави.
• Оставяне на превключватели „legacy” или „old-browser compatibility” включени. Много хостове и CDN имат опция, тихо реактивираща повредените версии или слабите шифри „за съвместимост.” Почти никога не помага на реален посетител и директно причинява тази находка.
• Забравяне за действително презареждане/рестартиране на сървъра. Конфигурационните промени не влизат в сила, докато уеб сървърът не бъде презареден — изненадващо честа причина „поправеният” сайт все още не преминава повторната проверка.
• Конфигуриране на един сървър, но не на всички. Ако управлявате load balancer, множество уеб сървъри или отделни поддомейни (shop, blog, app), всяка TLS крайна точка се нуждае от същата конфигурация — слабото е това, към което нападателят се насочва.

Какво да запомните

TLS версията и шифърът са двете части от вашето криптиране, реално движещи вашата оценка, и двете се свеждат до изключване на опции, публично повредени от години. Поправката е безплатна, обикновено е един съвременен конфигурационен ред за всеки сървър и за нормален посетител не променя нищо освен да направи връзката им наистина безопасна. Свързаните елементи — компресия, OCSP stapling, secure renegotiation — заслужава да знаете, но няма да засегнат вашата оценка, а при всяка съвременна настройка вече са обработени за вас.

ЧЗВ