Правилна конфигурация на TLS и HTTPS

Накратко: Надеждната TLS конфигурация на уеб сървър предлага само TLS 1.2 и TLS 1.3, използва набори от шифри (cipher suites) с Forward Secrecy и удостоверено шифроване (AES-GCM, ChaCha20-Poly1305) и сертификат с ECDSA или достатъчно дълъг RSA ключ, който се подновява автоматично. Ориентир дават насоките на BSI (Федералната служба за информационна сигурност на Германия) TR-02102-2 и препоръките Server-Side TLS на TLSRef. Проверете резултата отвън и не забравяйте връзките, които PHP сам изгражда.

Защо старите TLS настройки оцеляват толкова дълго

Катинарчето в браузъра го има, значи шифроването се смята за свършена работа. Така мислят много оператори и затова TLS конфигурацията често остава непроменена с години. Тя идва от времето на настройката на сървъра, от копиран шаблон или от стандартните стойности на един панел.

Проблемът: препоръките се променят. Версии на протоколи биват заменени, методи се смятат за слаби, добавят се нови методи за обмен на ключове. BSI публикува TR-02102 за последно във версия 2026-01 от 27.01.2026 г. и вече сочи там хибридни постквантови методи за TLS 1.3. Който не е поглеждал настройките си с години, най-вероятно вече не е на актуалното ниво.

Който така или иначе проверява сървъри след PHP2Shell, може да прегледа TLS конфигурацията наведнъж. Тя не затваря уязвимостта на PHP, но принадлежи към всяко прилично заздравяване.

На какво се опира добрата TLS конфигурация на уеб сървър

Два източника са особено полезни за оператори в Германия. BSI TR-02102 оценява криптографските методи; част 2 разглежда TLS. Тя е насочена най-вече към разработчици и проектанти и за държавни органи и регулирани сектори често е мерилото. Препоръките Server-Side TLS, които преди се поддържаха в уикито на Mozilla, днес се продължават в TLSRef и предлагат конкретни профили, готови за копиране.

TLSRef разграничава във версия 6.0 два профила:

За публичните уебсайтове Intermediate е обичайната отправна точка. Профилът изключва много стари устройства, но покрива актуалните браузъри и операционни системи. Хибридната група X25519MLKEM768 изисква актуална TLS библиотека. Проверете дали Вашата версия на OpenSSL я познава, преди да я въведете.

Nginx и Apache: сигурна отправна точка

Следващите примери реализират профила Intermediate. Пътищата са примерни стойности, списъкът с набори от шифри важи за TLS 1.2; TLS 1.3 носи собствени, сигурни стандартни методи.

server {
    listen 443 ssl;
    server_name www.example.de;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;
}

server {
    listen 80;
    server_name www.example.de;
    return 301 https://$host$request_uri;
}

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off

Вторият блок server пренасочва постоянно нешифрованите извиквания към HTTPS. Пренасочването трябва да сочи директно към крайния адрес и да не минава през няколко междинни спирки. След това проверете и вградените ресурси: изображения, скриптове или шрифтове, които още се зареждат през HTTP, предизвикват предупреждения в браузъра или биват блокирани.

Настройката клиентът да избира реда съответства на препоръката на TLSRef: всички предлагани методи се смятат за сигурни и устройства без AES ускорение така могат да предпочетат ChaCha20. След всяка промяна тествайте конфигурацията (nginx -t, съответно apachectl configtest) и презаредете услугата. Подходящата HSTS заглавна част и други указания за браузъра описва наръчникът Защитни заглавни части (headers) за уебсайтове.

Сертификати: ключ, верига, подновяване

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

Три правила помагат:

1. Подновявайте автоматично и наблюдавайте подновяването. Кратките срокове на валидност, каквито препоръчва TLSRef, са практични само с автоматизация.
2. Защитавайте частните ключове: четими само за root и за процеса на уеб сървъра, никога в уеб корена (webroot), никога в хранилище (repository).
3. Отчетете всички имена: основния домейн, www, поддомейни за магазин, staging, уеб интерфейс на пощата и панели.

Който използва сертификати на няколко места, например на CDN, балансьор на натоварването и първоизточник, трябва да води преглед: кой сертификат къде е инсталиран, кой го подновява и кога изтича. Когато този преглед липсва, изтекъл сертификат често се забелязва едва когато се обадят клиентите.

Как да проверите конфигурацията си отвън

Следващите команди са чисти проверки и не променят нищо. Заменете името на хоста със своето:

# TLS 1.3 и TLS 1.2 трябва да работят
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# TLS 1.1 трябва да се провали
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Срок и притежател на предоставения сертификат
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Неуспех при теста за TLS 1.1 може да се дължи и на това, че Вашата локална версия на OpenSSL изобщо не предлага вече стария протокол. За пълен отчет за всички предлагани методи е подходящ специализиран TLS скенер. Проверявайте при това всеки поддомейн поотделно, защото често работят със собствени настройки.

Забравено: TLS там, където PHP сам е клиент

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

<?php
// Сигурно: сертификатът и името на хоста се проверяват (запазете стандартното поведение)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
    CURLOPT_TIMEOUT        => 10,
]);
$antwort = curl_exec($ch);

Потърсете в кода CURLOPT_SSL_VERIFYPEER със стойност false и verify_peer в stream контексти. Всяко намерено място на практика премахва защитата на TLS за тази връзка. Където услугите са зад CDN, и участъкът между CDN и първоизточника трябва да използва валиден, проверяван сертификат. Допълнителни настройки на уеб сървъра за PHP конфигурации ще намерите в Сигурно конфигуриране на Nginx за PHP, мерила за цялостното заздравяване в CIS Benchmarks и модули на BSI.

Как помага PHP SOS конкретно?

• Отчитаме всички имена на хостове и услуги с TLS, включително панели, staging и уеб интерфейси на пощата.
• Сверяваме настройките с TR-02102 и подходящия профил на TLSRef и документираме съзнателните отклонения.
• Преминаваме сертификатите към автоматично подновяване с наблюдение.
• Търсим в кода на приложението изключени проверки на сертификати и показваме корекцията.

TLS е един от модулите на нашето заздравяване на сървъри за PHP уеб сървъри; връзката с актуалната ситуация обяснява Какво е PHP2Shell?.

Често задавани въпроси

Източници

• BSI TR-02102: Криптографски методи, част 2 TLS
• TLSRef: Server-Side TLS Guidelines
• Документация на Nginx
• Apache HTTP Server: документация