OpenSSL po poprawkach: jak zweryfikować wersję i zabezpieczyć serwery

Dlaczego OpenSSL po aktualizacjach wymaga ponownego przeglądu konfiguracji

Cel jest prosty: upewnić się, że serwery korzystają z bezpiecznej, aktualnej wersji OpenSSL, a konfiguracja TLS nie otwiera niepotrzebnych dziur. Sama obecność bibliotek w systemie nie wystarczy – liczy się konkretna wersja i to, jak jest używana przez usługi.

Częste poprawki bezpieczeństwa a stabilność usług

OpenSSL to jedna z najczęściej łatanych bibliotek w świecie linuksowych serwerów. Każda nowa wersja to z jednej strony poprawki bezpieczeństwa, z drugiej – ryzyko wpływu na stabilność usług. Zwykle dystrybucje wypuszczają backportowane łatki bezpieczeństwa, utrzymując numer głównej wersji, ale zmieniając łatane wydanie pakietu. Dlatego:

• wersja, którą pokazuje openssl version, nie zawsze mówi całą prawdę o poziomie załatek,
• usługa może korzystać z innej instancji OpenSSL niż ta, którą widać w konsoli,
• po aktualizacji pakietów same biblioteki nie „odświeżą się” w działających procesach – potrzebny jest restart usług.

Duże aktualizacje (np. przeskok z gałęzi 1.0.2 na 1.1.1) potrafią zmienić API, domyślne ustawienia i listę obsługiwanych szyfrów. Może to ujawnić błędy w starych aplikacjach lub spowodować odmowę połączeń z bardzo starymi klientami. Dlatego zamiast ślepo aktualizować produkcję, lepiej mieć prosty schemat: testy na środowisku testowym lub pojedynczym mało krytycznym serwerze, szybka weryfikacja, dopiero potem rolka dalej.

Zainstalowane vs bezpiecznie skonfigurowane

Serwer może mieć nową, załataną wersję OpenSSL, a mimo to przepuszczać połączenia po przestarzałych protokołach i szyfrach. Typowy przykład: OpenSSL 1.1.1 na serwerze www, ale konfiguracja Apache sprzed wielu lat, pozostawiająca wsparcie dla TLS 1.0 i TLS 1.1 „żeby nie psuć klientom”. Efekt – formalnie nowa biblioteka, ale ocena „F” w teście SSL/TLS.

Bezpieczna konfiguracja to głównie:

• sensowny minimalny poziom protokołu (TLS 1.2 lub 1.3),
• wyłączenie znanych słabych szyfrów (RC4, 3DES, EXPORT),
• wyłączenie starych rozszerzeń i funkcji, takich jak SSLv2/v3,
• odpowiednia długość kluczy i algorytmów podpisu certyfikatu.

Jeśli w infrastrukturze jest kilka serwisów (www, poczta, VPN, API), aktualizacja jednej usługi nie wystarczy. Wszystkie usługi korzystające z OpenSSL muszą być zrobione „w jednym ruchu” lub przynajmniej przejrzane – inaczej efekt prac jest połowiczny.

Skutki ignorowania aktualizacji i różnica efektu vs wysiłek

Zlekceważone poprawki OpenSSL rzadko kończą się spektakularną katastrofą z dnia na dzień, ale stopniowo psują reputację i zwiększają ryzyko. Przykładowe konsekwencje:

• Ostrzeżenia przeglądarek – jeśli serwer obsługuje tylko stare szyfry i protokoły, nowsze przeglądarki zaczynają blokować lub oznaczać połączenia jako niebezpieczne.
• Niższe oceny w audytach – klienci proszą o raport SSL/TLS, a serwer wypada słabo, co obniża wiarygodność.
• Realne wycieki danych – w skrajnym przypadku podatności typu Heartbleed czy Lucky 13 pozwalają wyciekać fragmentom pamięci lub osłabiają bezpieczeństwo sesji.
• Problemy z kompatybilnością – w pewnym momencie nowoczesne klienty przestają się łączyć, co wymusza nerwowe aktualizacje „na wczoraj”.

Kosztowo najlepiej wygląda scenariusz: regularne, krótkie okienka serwisowe, aktualizacja z repozytoriów, prosty re-test. Minimalny wysiłek: kilkanaście minut pracy i restart usług. W zamian:

• szybsze zamknięcie krytycznych CVE,
• brak nerwowych akcji pod presją czasu,
• klarowna dokumentacja kto, kiedy i co aktualizował.

Samo podniesienie wersji OpenSSL likwiduje znane błędy w bibliotece, ale bez zmiany konfiguracji TLS w usługach efekt jest często ograniczony. Sensowny schemat to: najpierw zidentyfikowanie wersji, potem mapa ryzyka, aktualizacja pakietów, na końcu korekta konfiguracji usług i krótki test z zewnątrz.

Jak sprawdzić wersję OpenSSL na różnych systemach

Podstawowe komendy: openssl version i rozszerzone informacje

Najtańszy czasowo krok to sprawdzenie, z jaką wersją OpenSSL ma się styczność w powłoce. Służą do tego dwie podstawowe komendy:

• openssl version – pokazuje główną wersję biblioteki, np. OpenSSL 1.1.1f 31 Mar 2020,
• openssl version -a – wyświetla dodatkowo datę kompilacji, informacje o platformie, opcjach kompilacji i ścieżkach do konfiguracji.

Przykładowe wyjście:

$ openssl version -a
OpenSSL 1.1.1f  31 Mar 2020
built on: Tue Mar 15 10:00:00 2022 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC ...
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

Istotne jest nie tylko to, jaki numer widać, ale też skąd pochodzi binarka. Jeżeli w systemie istnieje kilka instalacji OpenSSL (np. jedna systemowa, druga zbudowana ręcznie w /usr/local), komenda w powłoce może nie odpowiadać temu, z czego korzystają usługi.

Lokalizacja binariów: which, whereis, ścieżki systemowe

Żeby sprawdzić, skąd uruchamia się openssl, używa się standardowych narzędzi lokalizujących:

• which openssl – pokazuje ścieżkę używaną w aktualnej powłoce, np. /usr/bin/openssl,
• whereis openssl – może wskazać kilka lokalizacji binarki i plików man,
• type -a openssl (bash) – lista wszystkich dopasowań w kolejności przeszukiwania $PATH.

Typowe lokalizacje to:

• /usr/bin/openssl – standardowa lokalizacja w większości dystrybucji,
• /usr/local/bin/openssl – własnoręcznie instalowane wersje,
• /opt/... – wersje z dodatkowych repozytoriów lub aplikacji.

Jeżeli widać więcej niż jedną binarkę, warto jasno zdecydować, z której instalacji chce się korzystać. Z punktu widzenia bezpieczeństwa i budżetu utrzymania najlepiej trzymać się wersji zarządzanej przez system pakietów (apt, yum, dnf, zypper) – wtedy aktualizacje bezpieczeństwa „same przychodzą” przy regularnym apt upgrade lub yum update.

Różnice między dystrybucjami: Debian/Ubuntu, RHEL/CentOS/Alma, SUSE

Na rodzinie Debian/Ubuntu zwykle wystarczy:

openssl version
dpkg -l | grep -i openssl

Pakiet openssl dostarcza binarkę, a biblioteki udostępniane są jako libsslX.Y (np. libssl1.1, libssl3). Z kolei na RHEL/CentOS/AlmaLinux używa się:

openssl version
rpm -qa | grep -i openssl

i widać zwykle paczki typu openssl, openssl-libs, openssl-devel. SUSE (openSUSE, SLES) zachowuje się podobnie jak RHEL, ale zarządzanie odbywa się przez zypper.

Różnice bywają subtelne: w jednej dystrybucji nowa funkcja jest dostępna dopiero po zainstalowaniu nowszej gałęzi (np. openssl-1.1 obok openssl-1.0), w innej – istnieje tylko jedna, ale mocno załatana wersja. Dlatego przy porównywaniu z dokumentacją projektu OpenSSL trzeba brać pod uwagę, że dystrybucje często trzymają się starszego numeru głównego, ale regularnie backportują łatki bezpieczeństwa.

Sprawdzanie wersji OpenSSL na macOS i w Homebrew

macOS ma własną wersję narzędzi kryptograficznych, a przez długi czas systemowa binarka openssl była przestarzała i niezalecana do nowych projektów. Obecnie Apple promuje własne API (Secure Transport), a administratorzy zwykle instalują OpenSSL z Homebrew.

Typowe kroki:

which openssl
openssl version -a

Jeżeli ścieżka to /usr/bin/openssl, najpewniej używana jest wersja systemowa. Po zainstalowaniu z Homebrew:

brew install openssl
brew info openssl

narzędzie może lądować w /usr/local/opt/openssl@1.1/bin lub podobnym katalogu. Czasem trzeba dodać ścieżkę do $PATH, aby mieć pewność, że powłoka korzysta z wersji z Homebrew. Dobrą praktyką jest jasno udokumentować, z której wersji korzystają skrypty i usługi – inaczej po aktualizacji systemu może pojawić się nieoczekiwana zmiana.

Wersja OpenSSL na Windows: Git Bash, Cygwin, binarki w PATH

Na Windows sytuacja jest bardziej rozproszona. Może istnieć kilka źródeł OpenSSL:

• wbudowane w Git for Windows (Git Bash),
• dostarczone przez Cygwin/MSYS2,
• osobne binarki OpenSSL zainstalowane w C:Program FilesOpenSSL lub podobnie,
• własne binarki dołączone do aplikacji (np. serwera www dla Windows).

Najprościej uruchomić:

openssl version -a

w danym środowisku (Git Bash, PowerShell, CMD) i sprawdzić ścieżkę:

where openssl

w PowerShell/CMD lub:

which openssl

w środowiskach uniksowych (Git Bash, Cygwin). Z punktu widzenia bezpieczeństwa większość krytycznych serwerów produkcyjnych i tak stoi na Linuksie/BSD, ale jeżeli jakieś wewnętrzne narzędzie okienkowe korzysta z wbudowanego OpenSSL, również wymaga ono aktualizacji, szczególnie jeśli eksponuje usługi do sieci.

Jak rozpoznać, czy wersja OpenSSL jest bezpieczna względem aktualnych podatności

Jak czytać numery wersji OpenSSL (major, minor, patch, litery)

OpenSSL stosował przez lata dość nietypowy schemat wersjonowania. W wersjach 1.0.x i 1.1.x numer wyglądał np. tak: 1.1.1k. Oznacza to:

• 1 – wersja główna (major),
• .1 – wersja poboczna (minor),
• .1 – wydanie (patch level),
• k – dodatkowy poziom poprawek (litera im dalej w alfabecie, tym nowsze wydanie).

W gałęzi 3.x projekt przeszedł na bardziej standardową notację semver (3.0.0, 3.0.1 itd.). Przy ocenie podatności trzeba zwracać uwagę nie tylko na to, czy jest to 1.0.x czy 1.1.x, ale również na literkę na końcu. Przejście z 1.1.1f do 1.1.1n może oznaczać zamknięcie kilku istotnych CVE.

Źródła informacji o znanych CVE i mapowanie wersji

Żeby sprawdzić, czy posiadana wersja OpenSSL ma znane podatności, można skorzystać z kilku źródeł:

• strona projektu OpenSSL – sekcja „News” lub „Vulnerabilities” zawiera listę CVE z przypisanymi wersjami, których dotyczą,
• bazy CVE (np. cve.mitre.org, nvd.nist.gov) – można wyszukać OpenSSL i przejrzeć aktualne zgłoszenia,
• bezpieczeństwo dystrybucji (Debian Security Tracker, Red Hat CVE Database, SUSE Security Announcements) – pokazują, które wersje pakietów dystrybucji zawierają łatki,
• change log pakietów – apt changelog openssl, rpm -q --changelog openssl itp.

Z punktu widzenia budżetu czasowego najwydajniejsze jest korzystanie z dokumentacji dystrybucji. Dla przykładu: Debian może mieć w stabilnej wersji OpenSSL 1.1.1n, ale w changelogach widać, że kolejne wydania tej samej paczki zamykają konkretne CVE. Nie trzeba wtedy ręcznie mapować do numerów upstream; wystarczy sprawdzić, czy zainstalowana jest co najmniej wersja paczki, która „zamyka” daną podatność.

Prosty schemat:

1. Sprawdzenie: openssl version -a oraz wersji pakietu: dpkg -l | grep openssl lub rpm -qa | grep openssl.

Prosty workflow oceny bezpieczeństwa z perspektywy administratora

1. Odczytanie wersji OpenSSL oraz numeru pakietu systemowego.
2. Porównanie z informacją dystrybucji (tracker bezpieczeństwa, changelog).
3. Sprawdzenie, czy dana wersja znajduje się na liście „dotkniętych” w opisie CVE.
4. Jeśli dystrybucja oznacza pakiet jako „fixed”/„resolved” dla danego CVE, aktualizacja do minimum tej wersji.
5. Po aktualizacji – szybki test zewnętrzny (np. SSL Labs) i logów usług, czy nie ma regresji.

Taki schemat zamyka się zwykle w kilkunastu minutach na serwer i jest znacznie tańszy niż ręczne przekopywanie całej historii OpenSSL. Przy większej infrastrukturze można zautomatyzować krok pierwszy i drugi skryptami lub prostym systemem inwentaryzacji.

Granica „wystarczająco bezpiecznej” wersji a realne ryzyko

Nie każdy serwer wymaga najświeższej dostępnej gałęzi OpenSSL. Dla wewnętrznych usług dostępnych tylko z sieci lokalnej akceptowalne bywa utrzymanie wersji o 1–2 wydania wstecz, o ile wszystkie krytyczne CVE są załatane przez dystrybucję. Na węzłach wystawionych do Internetu sytuacja jest inna: podatność zdalna na zdalne wykonanie kodu czy prosty DoS może w kilka minut przełożyć się na przestój lub incydent bezpieczeństwa.

Praktyczne kryterium:

• serwery bezpośrednio dostępne z Internetu – OpenSSL w aktualnie wspieranej gałęzi (np. 1.1.1 z aktywnym wsparciem LTS lub 3.x),
• systemy krytyczne, ale za reverse proxy – dopuszczalne lekko starsze wersje, o ile front chroni je przed najczęstszymi wektorami ataku,
• środowiska testowe i labowe – tu wystarczy zbliżenie do produkcji; nadmierne „gonienie najnowszego” tylko zwiększa koszty utrzymania.

Warto też mieć z tyłu głowy daty EOL (End of Life) poszczególnych gałęzi OpenSSL. Po tej dacie upstream nie publikuje już poprawek bezpieczeństwa; dystrybucje czasem utrzymują własne łatki, ale długoterminowo lepiej zaplanować migrację niż łatać muzealne wersje.

Aktualizacja OpenSSL: proste ścieżki na popularnych dystrybucjach

Debian i Ubuntu: aktualizacje bezpieczeństwa przez APT

Na Debianie i Ubuntu mechanizm aktualizacji jest w praktyce najtańszą opcją utrzymania OpenSSL. Typowy scenariusz:

sudo apt update
sudo apt install --only-upgrade openssl libssl*

W większości przypadków wystarczy zwykłe:

sudo apt upgrade

ponieważ OpenSSL jest oznaczony jako pakiet krytyczny i poprawki bezpieczeństwa wpadają automatycznie. Kiedy wymagana jest konkretna wersja, przydaje się podgląd changeloga:

apt changelog openssl | less

Na serwerach z restrykcyjną polityką zmian wygodnie jest uruchomić najpierw suchy bieg:

sudo apt upgrade --dry-run

Takie podejście pokazuje, czy aktualizacja OpenSSL pociągnie za sobą aktualizację większej liczby bibliotek i usług. Jeśli lista jest długa, lepiej zaplanować krótki „okienko serwisowe”, zamiast robić to na żywym produkcie w środku dnia.

RHEL, CentOS Stream, AlmaLinux, Rocky: yum/dnf i kanały bezpieczeństwa

Na rodzinie RHEL/Alma/Rocky podstawowy zestaw komend to:

sudo yum check-update openssl
sudo yum update openssl

lub dla nowszych dystrybucji:

sudo dnf check-update openssl
sudo dnf update openssl

Dobrą praktyką jest zerknięcie, z którego repozytorium pochodzi aktualizacja:

yum info openssl
# albo
dnf info openssl

W środowiskach z restrykcyjnymi zasadami bezpieczeństwa często używa się osobnych repozytoriów z backportami (np. „rhel-7-server-rpms”, „rhel-7-server-optional-rpms”). Upewnienie się, że są włączone, jest zwykle tańsze niż próba budowania OpenSSL z źródeł dla całej farmy.

openSUSE i SLES: zypper i polityka patchy

Na SUSE aktualizacje OpenSSL są dostarczane przez standardowe kanały aktualizacji. Szybki przegląd dostępnych poprawek:

sudo zypper list-patches | grep -i openssl

Aktualizacja samego OpenSSL i powiązanych bibliotek:

sudo zypper update openssl libopenssl* libssl*

SUSE dość szczegółowo opisuje poprawki w advisories (SUSE Security Announcements). Zamiast zgadywać, czy konkretne CVE zostało załatane, prościej dopasować numer advisory do opisów pakietów w systemie i sprawdzić, czy są już zainstalowane.

FreeBSD i inne BSD: pkg oraz ports

Na FreeBSD serwery produkcyjne w większości korzystają z binarnych pakietów. Sprawdzenie dostępnej aktualizacji:

pkg version | grep -i openssl
pkg audit -F

pkg audit bardzo szybko wskazuje znane podatności. Aktualizacja do nowszej wersji:

sudo pkg upgrade openssl

Jeżeli OpenSSL został zainstalowany z ports, koszt utrzymania rośnie – każda aktualizacja to rekompilacja. Do pojedynczych serwerów jest to akceptowalne, ale przy większej skali bardziej opłaca się przejść na pakiety binarne i tylko krytyczne komponenty trzymać w ports.

macOS: aktualizacje systemowe vs Homebrew

Na macOS systemowe biblioteki kryptograficzne aktualizują się razem z systemem, co z punktu widzenia serwera www i tak zwykle nie ma znaczenia – realnie korzysta się z OpenSSL z Homebrew.

Prosty cykl aktualizacji:

brew update
brew upgrade openssl
brew info openssl

Po aktualizacji warto sprawdzić, czy nie zmieniła się ścieżka do binarek (czasem nowa wersja ląduje pod inną nazwą, np. openssl@3). Jeżeli gdzieś twardo wpisano ścieżkę typu /usr/local/opt/openssl@1.1/bin/openssl, zmiana gałęzi może wymagać ręcznej korekty skryptów.

Windows: kiedy aktualizować, a kiedy lepiej nie ruszać

Na Windowsie aktualizacja OpenSSL ma sens głównie wtedy, gdy jest faktycznie używany jako komponent serwera lub aplikacji. Dla samych narzędzi developerskich (np. OpenSSL z Git for Windows) często wystarczy poczekać, aż aktualizację wprowadzi sam dostawca pakietu.

W praktyce są trzy scenariusze:

• OpenSSL zainstalowany jako osobny pakiet (np. z Shining Light Productions) – aktualizacja przez instalator nowej wersji, po czym test usług zależnych,
• OpenSSL wbudowany w aplikację (np. serwer www, VPN) – aktualizacja całej aplikacji, nie samej biblioteki,
• Środowiska typu Cygwin/MSYS2 – aktualizacja przez ich menedżery pakietów (np. pacman -Syu w MSYS2).

Samodzielna podmiana plików DLL bez wsparcia producenta to oszczędność pozorna – jedna zła zgodność ABI może wygenerować więcej pracy niż zaplanowana aktualizacja całego produktu.

Spójność wersji: serwer www, poczta, VPN i inne usługi korzystające z OpenSSL

Jak ustalić, z jakiego OpenSSL korzysta konkretna usługa

Nawet jeśli openssl version pokazuje aktualną wersję, usługi mogą korzystać z innej kopii biblioteki (statycznie dołączonej albo z prywatnego katalogu). Kluczowe pytanie brzmi: „jakiego dokładnie OpenSSL używa proces, który słucha na porcie 443/993/1194?”.

Na Linuksie pomagają w tym narzędzia:

• ldd /ścieżka/do/binarki – pokazuje, z jakich bibliotek współdzielonych korzysta dany program (szukać libssl.so, libcrypto.so),
• lsof -p PID | grep -i ssl – listuje pliki otwarte przez proces o danym PID,
• strings /ścieżka/do/binarki | grep -i openssl – szybkie sprawdzenie zaszytych wersji (dla aplikacji statycznie linkowanych).

Przykład dla Nginx:

which nginx
ldd $(which nginx) | egrep 'ssl|crypto'

Jeżeli widać ścieżki typu /usr/lib/x86_64-linux-gnu/libssl.so.1.1, oznacza to, że Nginx korzysta z systemowej biblioteki i sama aktualizacja pakietu libssl wystarczy, żeby zamknąć podatności. Jeśli widać natomiast /usr/local/nginx/lib/libssl.so.1.1, trzeba traktować Nginx jako osobny „świat”, który należy przebudować lub zaktualizować z jego źródeł.

Webserwery: Apache, Nginx, HAProxy

Dla serwerów www liczą się dwa poziomy: wersja OpenSSL oraz konfiguracja TLS. Z perspektywy wersji:

• Apache httpd z repozytoriów dystrybucji – zwykle korzysta z systemowego OpenSSL, aktualizuje się razem z nim,
• Nginx – identycznie, o ile jest z pakietów dystrybucji; wersje zewnętrzne (np. własnoręcznie kompilowane) mają swoją kopię OpenSSL przy linkowaniu statycznym,
• HAProxy – podobnie; większość pakietów dystrybucji linkuje go do systemowych bibliotek.

Najbardziej budżetowo jest trzymać się pakietów z dystrybucji, bez własnej kompilacji OpenSSL/Nginx/HAProxy. Tam, gdzie konieczne są funkcyjności wyprzedzające dystrybucję (np. najnowsze rozszerzenia TLS, QUIC), sensownie jest wybrać jeden host „brzegowy” z nowszym stosem, a resztę środowiska opierać na standardowych pakietach.

Serwery poczty: Postfix, Dovecot, Exim

Dla MTA i serwerów IMAP/POP3 mechanizm jest podobny. Postfix i Dovecot z repozytoriów Debian/Red Hat domyślnie korzystają z systemowych bibliotek.

Kontrola dla Postfixa:

postconf -m | grep -i tls
ldd $(which smtpd) | egrep 'ssl|crypto'   # ścieżka może się różnić

Dovecot:

ldd $(which dovecot) | egrep 'ssl|crypto'

Jeśli biblioteka wskazuje na standardowy katalog dystrybucji, aktualizacja OpenSSL załatwia temat. Potem zostaje sprawdzenie konfiguracji TLS (o tym dalej). Osobne, ręcznie kompilowane wersje Postfixa z /usr/local wymagają więcej pracy przy aktualizacji; w większości organizacji zamiana ich na pakiety dystrybucji obniża koszty długoterminowe.

VPN: OpenVPN, stary OpenSSL a nowe wymagania

OpenVPN używa OpenSSL lub innych bibliotek kryptograficznych (np. mbedTLS) w zależności od kompilacji. Na serwerach z repozytoriów dystrybucji:

ldd $(which openvpn) | egrep 'ssl|crypto'

Jeżeli widoczny jest libssl z systemu, aktualizacja biblioteki zabezpiecza OpenVPN bez konieczności jego reinstalacji. W starszych systemach warto zwrócić uwagę na minimalne wersje TLS i obsługiwane algorytmy – samo załatanie CVE w bibliotece nie wyłączy np. TLS 1.0, co dla połączeń zdalnych może być nadal ryzykiem.

Inne usługi: bazodanowe, LDAP, reverse proxy

MySQL/MariaDB, PostgreSQL, OpenLDAP, a także mniej oczywiste komponenty (serwery cache, reverse proxy aplikacyjne) często korzystają z TLS przez OpenSSL. Z praktycznego punktu widzenia najbardziej przydatny jest prosty checklist:

• lista usług nasłuchujących na TLS (443, 587, 993, 995, 636, niestandardowe porty aplikacji),
• dla każdej – sprawdzenie linkowania ldd lub dokumentacji,
• ocena: „aktualizuje się razem z systemem” vs „wymaga własnego cyklu aktualizacji”.

Taką listę można utrzymywać w zwykłym arkuszu czy pliku tekstowym. Z perspektywy czasu i kosztu diagnostyki, jeden dobrze opisany plik bywa cenniejszy niż automatyczne skanery, które generują setki pozycji bez jasnego powiązania z odpowiedzialnym serwisem.

Szybkie testy z zewnątrz: jak zweryfikować konfigurację i protokoły TLS

Proste testy CLI: openssl s_client

Najtańszą metodą weryfikacji konfiguracji TLS jest użycie samego OpenSSL z linii poleceń. Podstawowe zapytanie:

openssl s_client -connect example.com:443 -servername example.com

Na wyjściu widać m.in.:

• negocjowany protokół (np. SSL-Session: Protocol : TLSv1.3),
• zestawy szyfrów (cipher suite),
• łańcuch certyfikatów.

Test dla konkretnej wersji TLS:

Wymuszanie konkretnych protokołów i szyfrów

Ten sam s_client pozwala szybko sprawdzić, czy serwer jeszcze wpuszcza przestarzałe protokoły. Najczęstsze testy:

# Test tylko TLS 1.0
openssl s_client -connect example.com:443 -tls1

# Test tylko TLS 1.1
openssl s_client -connect example.com:443 -tls1_1

# Test tylko TLS 1.2
openssl s_client -connect example.com:443 -tls1_2

# Test tylko TLS 1.3
openssl s_client -connect example.com:443 -tls1_3

Jeżeli dla TLS 1.0/1.1 połączenie nadal się zestawia, konfiguracja wymaga korekty – szczególnie przy usługach wystawionych do internetu. W wielu środowiskach wewnętrznych rezygnacja z TLS 1.0/1.1 nie powoduje realnych problemów, natomiast znacząco upraszcza kwestie zgodności z normami i wytycznymi audytorów.

Można też zawęzić test do konkretnego zestawu szyfrów:

openssl s_client -connect example.com:443 
  -servername example.com 
  -cipher 'AES128-SHA'

Jeśli serwer akceptuje szyfry bez PFS (bez ECDHE/DHE) lub stare konstrukcje typu DES, 3DES, to sygnał, że konfiguracja TLS dawno nie była ruszana. Z biznesowego punktu widzenia to dokładnie ten przypadek, w którym małe kilka linijek w konfiguracji zamyka klasę ryzyk, które w raportach zewnętrznych pen-testów wyglądają „drogo”.

Testy z wykorzystaniem nmap i prostych skryptów NSE

Dla większej liczby hostów wygodniej podpiąć coś bardziej automatycznego niż ręczne odpalanie openssl. Wbudowane skrypty nmap radzą sobie z tym całkiem dobrze, a nie wymagają budowy skomplikowanej infrastruktury skanującej.

nmap --script ssl-enum-ciphers -p 443 example.com

Raport z ssl-enum-ciphers podaje listę obsługiwanych protokołów i szyfrów, wraz z oceną ich siły. To wystarcza, żeby w godzinę przejrzeć kilkanaście hostów i stwierdzić, gdzie trzyma się jeszcze stary profil TLS „dla jednego klienta z Windows XP”.

Dla bardziej syntetycznego spojrzenia można użyć:

nmap --script ssl-cert,ssl-enum-ciphers -p 443,993,995,587,465 host.example.com

Takie jednorazowe skanowanie bywa skuteczniejsze niż roczne deklaracje w dokumentacji, że „wszystkie serwery są już na TLS 1.2+”. Narzędzie nie ma sentymentów, po prostu pokazuje, co naprawdę jest wystawione na portach.

Serwisy zewnętrzne: kiedy mają sens, a kiedy nie

Popularne skanery www (typu SSL Labs) dają bardzo czytelny raport dla serwerów HTTP/HTTPS w internecie. W praktyce używane są najczęściej tak:

• do przeglądu usług dostępnych publicznie – szczególnie tych z domeną firmową,
• do porównania z innymi: „jaki mamy rating vs konkurencja/partnerzy”,
• jako argument w rozmowie z działem biznesu, kiedy trzeba włączyć silniejsze wymagania co do TLS.

W środowiskach zamkniętych, bez dostępu z internetu, większy sens ma własny, lekki zestaw narzędzi: openssl, nmap, ewentualnie skrypty w Pythonie z użyciem ssl. W wielu organizacjach taka paczka „skanerów” mieszcząca się w jednym katalogu na laptopie admina rozwiązuje 80% potrzeb bez konieczności stawiania centralnego narzędzia klasy enterprise.

Praktyczna konfiguracja OpenSSL / TLS na serwerze www po poprawkach

Ustalenie minimalnych wymagań biznesowych i technicznych

Zanim zacznie się przepisywać konfigurację TLS, dobrze jest określić dolną granicę kompatybilności. Inaczej wygląda sytuacja sklepu internetowego z klientami z całego świata, a inaczej wewnętrznego panelu administracyjnego.

Najprostszy podział:

• usługi zewnętrzne dla „typowego internetu” – minimum TLS 1.2, najlepiej z obsługą TLS 1.3,
• usługi wewnętrzne / administracyjne – TLS 1.2+ z agresywnym wycięciem starych szyfrów, słabsza kompatybilność bywa akceptowalna,
• integracje z partnerami – osobne wirtualne hosty lub porty, gdzie dopuszcza się np. szerszy zestaw szyfrów, ale kontrolowany.

Ten etap zwykle nie wymaga jeszcze zmian konfiguracyjnych, za to pozwala uniknąć późniejszych cofnięć typu „wyłączyliśmy TLS 1.0, ale okazało się, że system X wciąż go potrzebuje”. Dla najbardziej problematycznych integracji da się czasem postawić mały, dedykowany reverse proxy z „gorszym” profilem TLS, zamiast obniżać bezpieczeństwo całej infrastruktury.

Przykładowa konfiguracja TLS w Nginx po aktualizacji OpenSSL

Dla aktualnych dystrybucji (OpenSSL 1.1.1 lub 3.x) rozsądny, budżetowy profil Nginx może wyglądać tak:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_prefer_server_ciphers on;

ssl_ciphers
  'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:'
  'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:'
  'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256';

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;

Ta konfiguracja wycina TLS 1.0/1.1 oraz słabsze szyfry, ale nadal dogaduje się z większością klientów z ostatnich lat. W większych środowiskach warto mieć taki „domyślny profil Nginx” w jednym pliku, współdzielony przez wszystkie vhosty – modyfikuje się wtedy jeden fragment, a nie kilkanaście kopii w różnych plikach konfiguracyjnych.

Konfiguracja Apache httpd z modułem mod_ssl

W Apaczu analogiczny efekt można osiągnąć następująco:

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

SSLCompression          off
SSLSessionTickets       off

SSLUseStapling          on
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Dalsze „dogniatanie” konfiguracji (np. wymuszanie HSTS) lepiej trzymać bliżej warstwy aplikacyjnej lub polityk bezpieczeństwa, natomiast powyższy zestaw reguł daje sensowną bazę bez konieczności miesięcznego tuningu.

Wspólny plik z polityką TLS dla wielu usług

Przy kilku serwerach WWW i pocztowych łatwo wpaść w pułapkę: każdy administrator ustawia „swój” zestaw szyfrów, a po roku nikt już nie wie, gdzie co działa. Rozwiązaniem jest spójna, mała polityka TLS spisana w jednym miejscu i – tam, gdzie się da – ujęta w osobnym pliku konfiguracyjnym wciąganym przez usługi.

Przykład dla Nginx:

# /etc/nginx/snippets/tls.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers   <...jak wyżej...>;
ssl_prefer_server_ciphers on;

A w vhostach tylko:

include snippets/tls.conf;

Podobny wzorzec da się zastosować w Apaczu (Include), HAProxy (global / defaults) czy Postfixie (konsekwentne użycie tych samych zestawów parametrów w main.cf). Koszt wdrożenia takiej „mini-standaryzacji” jest niski, a oszczędza czas przy każdym kolejnym przeglądzie lub audycie.

Reakcja na nowe CVE: kiedy zmieniać konfigurację, a kiedy tylko aktualizować pakiety

Nie każde nowe CVE w OpenSSL wymaga natychmiastowego grzebania w konfiguracji TLS. W dużym skrócie:

• luki w implementacji protokołu / parsowania rekordów – zwykle wystarczy aktualizacja pakietów i restart usług korzystających z biblioteki,
• problemy w konkretnych algorytmach (np. w trybie CBC, starych szyfrach) – może być sens doraźnie wyłączyć dane szyfry w konfiguracji, zanim dotrze aktualizacja,
• błędy w obsłudze X.509, ASN.1 itp. – w większości przypadków ponownie: aktualizacja biblioteki + restart.

Najbardziej opłacalny proces na dłuższą metę to prosty schemat:

1. monitorowanie biuletynów bezpieczeństwa dla dystrybucji (np. RSS/maile z Debian Security, Red Hat Security),
2. szybka klasyfikacja: „dotyczy/nie dotyczy” używanych usług (np. tylko klient, a serwer i tak nie korzysta),
3. jeśli „dotyczy” – wpisanie aktualizacji do najbliższego okna serwisowego + krótki test po stronie aplikacji.

Ręczne łatki w konfiguracji (wyłączanie szyfrów, doraźne obejścia) mają sens głównie wtedy, gdy okno aktualizacji systemu jest bardzo ograniczone, a zagrożenie – istotne. W normalnym cyklu życia serwera tańsze jest utrzymywanie regularnych, zaplanowanych aktualizacji niż seria gorących poprawek robionych pod presją czasu.

Testy po zmianach: minimalny, ale regularny zestaw

Przy każdej istotniejszej zmianie w konfiguracji OpenSSL/TLS dobrze utrwalić prosty, powtarzalny zestaw testów. Nie musi to być rozbudowana automatyzacja – dla wielu zespołów wystarczy plik tekstowy z kilkoma komendami wykonywanymi po każdej aktualizacji.

Przykładowy „zestaw minimum” dla serwera WWW:

# 1. Sprawdzenie certyfikatu i łańcucha
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# 2. Weryfikacja braku TLS 1.0/1.1
openssl s_client -connect example.com:443 -tls1  < /dev/null
openssl s_client -connect example.com:443 -tls1_1 < /dev/null

# 3. Kontrola TLS 1.2/1.3
openssl s_client -connect example.com:443 -tls1_2 < /dev/null
openssl s_client -connect example.com:443 -tls1_3 < /dev/null

# 4. Krótki test przeglądarką z zewnątrz / z innej podsieci

To kilka minut pracy, a pozwala wychwycić większość prostych błędów (np. błędny redirect po HTTPS, zły certyfikat, brak obsługi danej wersji TLS) zanim zrobi to klient końcowy lub skaner zewnętrzny. W środowiskach, gdzie brakuje czasu na napisanie pełnych testów automatycznych, takie „checklisty w pliku” są często najbardziej opłacalnym kompromisem między jakością a nakładem.