OpenSSL 3.x: ulepszenia bezpieczeństwa dla systemów hostingowych

Zastosowanie OpenSSL 3.x w hostingu

OpenSSL to biblioteka zawierająca funkcje kryptograficzne oraz protokół TLS. Udostępnia ona aplikacjom między innymi metody szyfrowania, podpisywania, weryfikacji certyfikatów oraz nawiązywania bezpiecznych połączeń. Aktualizacja do OpenSSL 3.x W związku z tym poprawia przede wszystkim infrastrukturę kryptograficzną systemu hostingowego, a nie automatycznie wszystkie ustawienia usług działających w tym systemie.

To, czy serwer WWW, serwer pocztowy, serwer proxy odwrotny czy usługa bazy danych faktycznie korzysta z protokołu TLS oraz jakie zasady mają w tym przypadku zastosowanie, zależy od ich własnej konfiguracji. Na przykład NGINX, Apache, HAProxy, Postfix, Dovecot lub klient bazy danych wybierają wersje protokołów, certyfikaty, klucze i dozwolone metody. Zainstalowana biblioteka udostępnia w tym celu odpowiednie funkcje; nie zastępuje ona jednak starannie opracowanej polityki TLS poszczególnych usług.

Wzrost bezpieczeństwa wynika przede wszystkim z obsługiwanej wersji biblioteki, zmodernizowanych interfejsów programistycznych oraz wyraźniejszego oddzielenia starszych metod kryptograficznych. Zmniejsza to ryzyko, że aplikacje będą nieświadomie nadal korzystać z przestarzałych mechanizmów. Należy jednak pamiętać o terminowym instalowaniu aktualizacji zabezpieczeń, a łańcuchy certyfikatów, klucze prywatne oraz uprawnienia dostępu pozostają odrębnymi zadaniami operacyjnymi.

W praktyce dotyczy to zarówno połączeń publicznych, jak i wewnętrznych. W przypadku strony internetowej protokół TLS zabezpiecza trasę między przeglądarką a serwerem proxy odwrotnym; w tle mogą istnieć dodatkowe połączenia TLS między serwerem proxy a serwerem aplikacji lub między aplikacją a bazą danych. Każda trasa ma własne strony przeciwne i wymagania dotyczące kompatybilności. Nowoczesna biblioteka stanowi w tym zakresie ważną podstawę, ale nie gwarantuje, że wszystkie połączenia są zabezpieczone w spójny sposób.

Szczególnej uwagi wymagają aplikacje z własną integracją kryptograficzną. OpenSSL 3 wykorzystuje dostawców i preferuje abstrakcyjne interfejsy EVP, podczas gdy wiele starszych interfejsów API niskiego poziomu oraz mechanizmów ENGINE uznaje się za przestarzałe. W związku z tym podczas aktualizacji istotne znaczenie może mieć nie tylko konfiguracja usługi, ale także wtyczka, powiązanie językowe lub rozszerzenie własne.

Jak prawidłowo wybrać obsługiwane gałęzie wersji 3.x

Sformułowanie „aktualizacja do OpenSSL 3“ jest zbyt nieprecyzyjne z punktu widzenia planowania operacyjnego. 19 października 2026 r. na oficjalnej stronie pobierania jako regularnie dostępne gałęzie wersji 3.x wymienione będą już tylko wersje 3.4, 3.5 i 3.6. Wersje niewymienione na liście nie otrzymują publicznego wsparcia ze strony twórców projektu i zgodnie z zaleceniami OpenSSL nie powinny być już wykorzystywane w środowisku produkcyjnym. OpenSSL 3.0 i 3.3 nie stanowią zatem odpowiedniej podstawy dla nowych planów wdrożeń produkcyjnych.

W przypadku nowych projektów w ramach rodziny 3.x należy OpenSSL 3.5 LTS główna gałąź. Jej wsparcie techniczne ma trwać do 8 kwietnia 2030 r. Wsparcie dla OpenSSL 3.4 wygaśnie już 22 października 2026 r., a dla OpenSSL 3.6 – jako gałęzi niebędącej LTS – 1 listopada 2026 r. Osoby samodzielnie zarządzające pakietami upstream muszą zatem wziąć pod uwagę konkretną gałąź i datę zakończenia jej wsparcia.

W przypadku pakietów dystrybucji Linuksa nie należy oceniać ciągu znaków wersji upstream w oderwaniu od kontekstu. Zamiast tego należy sprawdzić w oficjalnych informacjach dotyczących pakietów, bezpieczeństwa i cyklu życia danego dostawcy dystrybucji, czy konkretna wersja pakietu jest nadal utrzymywana. Na podstawie dostępnych źródeł OpenSSL nie można sformułować ogólnych wniosków dotyczących procedur aktualizacji lub backportowania w poszczególnych dystrybucjach.

Zgodnie z polityką wersjonowania, w ramach głównej gałęzi 3 interfejsy API i ABI pozostają niezmienione w wydaniach pomniejszych; wydania poprawkowe zawierają poprawki błędów i zabezpieczeń. Niemniej jednak konieczne jest przeprowadzenie testów aplikacji, zwłaszcza w przypadku przestarzałych interfejsów, własnych dostawców, modułów sprzętowych lub dołączonych środowisk uruchomieniowych. Ponadto kontenery i aplikacje linkowane statycznie mogą korzystać z biblioteki innej niż ta używana przez system hosta.

Celem nie jest zatem uzyskanie jak najwyższego numeru wersji, lecz zapewnienie, by każdy faktycznie używany komponent miał wersję, która jest w sposób potwierdzony obsługiwana i może być aktualizowana. Samodzielna kompilacja z źródeł upstream zwiększa zakres odpowiedzialności: aktualizacje, ścieżki bibliotek i dostawców, skróty oraz testy kompatybilności muszą być wówczas kontrolowane przez operatora.

TLS nie jest szyfrowaniem nośnika danych

Protokół TLS chroni dane podczas ich przesyłania między określonymi punktami końcowymi. W przypadku wywołania strony internetowej dotyczy to na przykład połączenia między przeglądarką a serwerem WWW; w przypadku protokołu SMTP może to zabezpieczać przesyłanie danych między serwerami pocztowymi lub pobieranie treści ze skrzynki pocztowej. OpenSSL udostępnia aplikacjom moduły kryptograficzne do tego celu, jednak konkretne wykorzystanie protokołu TLS jest sterowane przez daną usługę.

Również połączenia wewnętrzne wymagają takiego samego rozdzielenia. Aplikacja może korzystać z protokołu TLS w komunikacji z bazą danych, z serwera proxy odwrotnego w komunikacji z zapleczem lub z serwera pocztowego w roli serwera przekaźnikowego. W takich przypadkach weryfikacja certyfikatów, sprawdzanie nazw hostów oraz zarządzanie certyfikatami zaufanymi są równie ważne, jak w przypadku usług dostępnych publicznie. Szyfrowanie w sieci nie zapewnia jednak automatycznej ochrony danych przetwarzanych lub przechowywanych w punkcie końcowym.

Szyfrowanie danych w spoczynku należy do innej warstwy. Szyfrowanie w systemie Linux może na przykład obejmować woluminy zaszyfrowane za pomocą LUKS; bazy danych mogą korzystać z własnych funkcji szyfrowania, a kopie zapasowe wymagają odrębnej procedury. Środki te określają, jakie dane są chronione w przypadku utraty nośnika danych, nieuprawnionego dostępu do plików kopii zapasowych lub dostępu do przechowywanych danych. Aktualizacja OpenSSL nie konfiguruje automatycznie żadnego z tych poziomów.

Skuteczna strategia szyfrowania łączy zatem ochronę danych podczas przesyłania i przechowywania, nie utożsamiając jednak tych dwóch aspektów. W przypadku protokołu TLS wymagane są ważne certyfikaty, zabezpieczone klucze prywatne oraz polityka protokołów dostosowana do danej usługi. W przypadku danych przechowywanych dochodzą do tego zarządzanie kluczami, uprawnienia, procedury odzyskiwania danych oraz ochrona kopii zapasowych. Jeśli klucze są przechowywane bez zabezpieczenia obok zaszyfrowanych kopii zapasowych, praktyczna ochrona pozostaje ograniczona.

Właściwe pytanie kontrolne brzmi zatem dla każdego przepływu danych: gdzie powstają dane, jaką trasą przechodzą, gdzie są trwale przechowywane i kto może korzystać z odpowiednich kluczy? OpenSSL może być wykorzystywany w protokole TLS i innych operacjach kryptograficznych. Nie stanowi on jednak ani zamiennika szyfrowania woluminów, ani kompletnego systemu zarządzania kluczami, ani gwarancji bezpiecznych kopii zapasowych.

Zrozumienie modelu dostawcy i poziomów bezpieczeństwa

W OpenSSL 3 implementacje kryptograficzne odbywają się za pośrednictwem Dostawca udostępniane i wybierane na podstawie właściwości. Dzięki temu kwestia wyboru algorytmu jest oddzielona od konkretnej implementacji. Ma to znaczenie w przypadku systemów hostingowych, ponieważ aplikacja, kontekst biblioteki oraz konfiguracja OpenSSL wspólnie określają, które metody są dostępne i można je wybrać.

Dostawca starszej wersji nie jest ładowany automatycznie. Jeśli starsza aplikacja wymaga algorytmu dostępnego wyłącznie w tym dostawcy, odpowiednie wywołanie może zakończyć się niepowodzeniem po aktualizacji. Jako tymczasowy wyjątek jego aktywacja musi być ograniczona do danej usługi, udokumentowana i powiązana z terminem wycofania.

Jeśli dostawcy zostaną wyraźnie aktywowani, domyślny dostawca nie będzie już automatycznie dostępny. Należy go dodatkowo załadować, jeśli aplikacja potrzebuje jego implementacji. Samo załadowanie dostawcy starszego typu nie oznacza jednak, że usługa sieciowa automatycznie korzysta ze starszych procedur; decydujące znaczenie mają żądane algorytmy, zapytania o właściwości oraz odpowiedni kontekst biblioteki.

Dostawca FIPS nie jest ogólnym certyfikatem bezpieczeństwa. Cechy takie jak fips=yes mają wpływ na wybór odpowiednich implementacji, ale same w sobie nie gwarantują zgodności z przepisami. Decydujące znaczenie ma konkretny, zatwierdzony moduł oraz jego polityka bezpieczeństwa. W momencie przeprowadzania badania strona pobierania OpenSSL podaje wersję OpenSSL 3.1.2 jako wersję zatwierdzoną zgodnie z normą FIPS 140-3.

Die Poziom bezpieczeństwa jest od tego oddzielona. Oprócz zestawów szyfrów wpływa ona również na podpisy, rozmiary kluczy i parametry. Globalne ustawienie, takie jak @SECLEVEL=2 może zatem wykluczyć niektóre certyfikaty lub stacje przeciwne. Sprawdź, jak zmiana wpłynie na odpowiednie usługi i klienty, zamiast wyciągać wnioski o wyższym poziomie bezpieczeństwa wyłącznie na podstawie krótszej listy algorytmów szyfrowania.

Konfiguracja zasad TLS dla poszczególnych usług

OpenSSL udostępnia reguły i funkcje kryptograficzne, ale skuteczna Polityka TLS jest realizowane przez każdą usługę w ramach jej własnej konfiguracji. Dotyczy to zarówno publicznych usług internetowych, jak i serwerów proxy odwrotnych oraz usług pocztowych, a obejmuje między innymi minimalne wymagania dotyczące protokołów, certyfikatów, kluczy oraz sposobu obsługi różnych podmiotów po drugiej stronie połączenia. W przypadku połączeń wewnętrznych, na przykład między serwerem proxy, aplikacją a bazą danych, obowiązują te same podstawowe kwestie, jednak często przy łatwiejszej do kontrolowania puli klientów.

Po pierwsze, usługa powinna dopuszczać wyłącznie te wersje protokołów, które są obsługiwane przez jej docelowe stacje końcowe. Następnie należy uwzględnić pełny łańcuch certyfikatów oraz typ klucza odpowiedni do danego zastosowania. Decyzji tych nie można sensownie traktować jako jednego globalnego ustawienia OpenSSL: publiczny serwer WWW, transport SMTP oraz wewnętrzny backend bazy danych mają różne ograniczenia dotyczące kompatybilności i zaufania.

W przypadku konfiguracji szyfrów decydujące znaczenie ma ograniczenie protokołu. Ciągi szyfrów OpenSSL sterują protokołem TLS 1.2 i starszymi wersjami TLS; zestawy szyfrów TLS 1.3 konfiguruje się oddzielnie. Ponadto z wyboru szyfrów nie wynika, jaką wersję protokołu TLS negocjuje serwer. Kto zmienia jedynie listę szyfrów, nie wyłącza tym samym automatycznie starych protokołów ani nie wykorzystuje w pełni możliwości TLS 1.3.

Wydanie openssl ciphers nie stanowi potwierdzenia aktywnej polityki serwera. Opisuje jedynie, jakie elementy biblioteka CLI zasadniczo rozpoznaje na podstawie swoich parametrów; certyfikat, parametry DH oraz konfiguracja usługi mogą dodatkowo ograniczać zestawy protokołów, które faktycznie można wynegocjować. Wiarygodny jest dopiero test przeprowadzony w odniesieniu do konkretnej usługi z przewidzianą nazwą serwera, certyfikatem i profilem klienta.

W przypadku usług pocztowych niezbędny wyjątek nie powinien obniżać poziomu zabezpieczeń wszystkich wirtualnych hostów ani wszystkich połączeń wychodzących. Lepiej jest wprowadzić udokumentowany, czasowy wyjątek dla znanego partnera, połączony z zleceniem migracji skierowanym do jego operatora. Zmiany TLS w architekturach proxy i sesji o wysokiej dostępności wymagają ponadto zaplanowanego przełączenia oraz udokumentowanego planu awaryjnego. Jeśli platforma wykorzystuje Redis do obsługi sesji lub kolejek, należy również uwzględnić Strategie przełączania awaryjnego Redis dla systemów hostingowych w środowisku produkcyjnym należy wziąć pod uwagę, aby ponowne uruchomienie spowodowane protokołem TLS nie zostało pogorszone przez nieprzygotowane przełączenie serwera zaplecza.

Kontrolowane przygotowanie i sprawdzenie migracji

Kontrolowana migracja zaczyna się od Inwentaryzacja. Zarejestruj procesy związane z siecią, pocztą elektroniczną, serwerami proxy, bazami danych i aplikacjami, a także kontrahentów TLS oraz szczególne zależności kryptograficzne. Odróżnij pakiet systemu operacyjnego od bibliotek, które są dostarczane wraz z kontenerami, panelami hostingowymi lub dołączonymi środowiskami uruchomieniowymi.

Najpierw wprowadź zmianę w środowisku testowym, wykorzystując realistyczne łańcuchy certyfikatów, nazwy i profile klientów. Stan pakietów, konfiguracja, pliki dostawców oraz kolejność ponownego uruchamiania muszą być ustalone przed rozpoczęciem okna serwisowego. Należy zwrócić szczególną uwagę na zewnętrznych partnerów pocztowych, starsze urządzenia oraz usługi wewnętrzne, których certyfikaty lub protokoły nie są zarządzane centralnie.

Poniższe polecenie diagnostyczne nie zmienia konfiguracji serwera i może być wykonywane wyłącznie w odniesieniu do udostępnionej domeny testowej. Ustawia ono SNI oraz weryfikację nazwy hosta; -verify_return_error przerywa wywołanie w przypadku błędu walidacji, zamiast kontynuować połączenie.

openssl s_client -connect <hostname>:443 -servername <hostname> -verify_hostname <hostname> -verify_return_error -brief

Wywołanie to sprawdza konkretny proces negocjacji TLS dla podanej nazwy hosta. Nie zastępuje ono testów innych portów, hostów wirtualnych, połączeń wewnętrznych ani klas klientów. Aby zapewnić rzetelną akceptację, należy zatem sprawdzić wszystkie istotne ścieżki usługowe z reprezentatywnymi stacjami końcowymi.

Po zmianie należy monitorować logi serwisowe, błędy certyfikatów oraz nieudane procedury uzgadniania połączenia. Awarie należy najpierw przypisać do certyfikatu, protokołu, wyboru szyfrowania lub zależności od aplikacji. Ogólne obniżenie poziomu bezpieczeństwa lub trwałe włączenie dostawcy legacy może przesłonić przyczynę i nie stanowi odpowiedniego standardowego rozwiązania awaryjnego.

Ukierunkowana analiza problemów z kompatybilnością

Po aktualizacji OpenSSL problem kompatybilności często ujawnia się dopiero podczas nawiązywania połączenia: przeglądarka, partner pocztowy lub klient wewnętrzny otrzymuje błąd TLS, mimo że sama usługa została uruchomiona. Nie należy wtedy od razu zmieniać list szyfrów ani poziomów bezpieczeństwa. Najpierw przypisz błąd do jednego z czterech poziomów: certyfikat, protokół, negocjacja szyfrowania lub aplikacja. Pozwoli to zawęzić zakres wyjątków do rzeczywistej przyczyny.

W przypadku certyfikatów szczególnie istotne jest to, że certyfikaty końcowe podpisane algorytmem SHA-1 nie są akceptowane od poziomu bezpieczeństwa 1. Również zbyt małe parametry klucza lub niekompletny łańcuch certyfikatów mogą uniemożliwić nawiązanie połączenia. Należy zatem sprawdzić faktycznie dostarczony certyfikat, w tym łańcuch certyfikatów i algorytm podpisu, zamiast ograniczać się wyłącznie do pliku certyfikatu przechowywanego na serwerze.

Jeśli połączenie ze starszym urządzeniem docelowym nie powiedzie się, przyczyną może być maksymalna wersja protokołu tego urządzenia. OpenSSL 3 nie traktuje już protokołów SSL 3.0, TLS 1.0, TLS 1.1 i DTLS 1.0 jako użytecznych przy domyślnym poziomie bezpieczeństwa 1. Tego rodzaju problem wymaga podjęcia decyzji o wymianie, aktualizacji lub ściśle ograniczonej kompatybilności przejściowej – a nie automatycznego obniżenia ogólnych standardów bezpieczeństwa.

Jeśli brakuje skrótu lub algorytmu szyfrowania, przyczyną jest często oczekiwany Algorytm starszej generacji. Moduł Legacy Provider nie jest ładowany automatycznie i zawiera procedury, które nie są już powszechnie stosowane lub zostały uznane za niebezpieczne. Jego tymczasowa aktywacja może zapewnić dostępność starszej aplikacji na czas udokumentowanej migracji; nie jest to jednak standardowy środek zabezpieczający i należy określić datę wygaśnięcia.

W przypadku oprogramowania własnego lub zastrzeżonego należy dodatkowo sprawdzić jego integrację z funkcjami kryptograficznymi. Moduły ENGINE oraz liczne wywołania niskopoziomowe dla algorytmów RSA, EC i innych są w OpenSSL 3 uznawane za przestarzałe; aplikacje powinny zostać przeniesione na abstrakcyjne interfejsy EVP. Jest to ważniejsze niż maskowanie komunikatu o błędzie wynikającego z konfiguracji dostawcy, ponieważ stare wywołania mogą ominąć żądany wybór dostawcy.

A Konfiguracja dostawcy musi być kompletna. Gdy tylko konfiguracja wyraźnie aktywuje innych dostawców, domyślny dostawca nie jest już ładowany automatycznie. Jeśli na przykład skonfigurowano wyłącznie starszą wersję, mogą brakować nowoczesnych standardowych implementacji, co może spowodować nieoczekiwaną awarię usługi. Dlatego należy świadomie ładować wymaganych dostawców, przetestować konkretny proces usługi po ponownym uruchomieniu i usunąć reguły przejściowe, gdy tylko zależny komponent zostanie zaktualizowany.

Prawidłowa ocena FIPS i przypadków szczególnych

Der Dostawca FIPS stanowi sensowny element systemów hostingowych tylko wtedy, gdy konkretne wymagania umowne, urzędowe lub wewnętrzne nakładają obowiązek stosowania kryptografii zatwierdzonej zgodnie z FIPS. Nie jest to ogólny znak jakości potwierdzający bezpieczeństwo protokołu TLS. OpenSSL oferuje koncepcję dostawcy FIPS; implementacje można rozróżniać na podstawie takich właściwości, jak fips=yes można wybrać. Jednak samo to nie sprawia, że ani instalacja, ani gałąź OpenSSL 3.5 stają się zatwierdzonym modułem FIPS.

Aby przeprowadzić rzetelną ocenę zgodności, należy osobno sprawdzić wymagania i kwestie techniczne: treść wytycznych, konkretną, zatwierdzoną wersję modułu wraz z certyfikatem i polityką bezpieczeństwa, zalecaną ścieżkę kompilacji i instalacji, pakiet dystrybucyjny oraz obsługę przez każdą z zainteresowanych usług. 19 października 2026 r. strona pobierania OpenSSL będzie wskazywać OpenSSL 3.1.2 jako wersję zatwierdzoną zgodnie z FIPS 140-3 i wymaga przestrzegania instrukcji zawartych w odpowiedniej polityce bezpieczeństwa dotyczącej pobierania, kompilacji i instalacji.

Nawet w przypadku prawidłowo zainstalowanego i zatwierdzonego modułu zgodność z przepisami zależy od rzeczywistego trybu pracy. Dokumentacja wskazuje, że przy fips=yes algorytmy pobrane mogą jednak w pewnych warunkach nie zostać uznane za dopuszczalne. Zastosowanie, zapytania o właściwości, wykorzystane algorytmy oraz konkretna ścieżka połączenia muszą zatem być zgodne z wytycznymi; samo załadowanie dostawcy lub fragmentu konfiguracji nie wystarczy.

Należy zachować szczególną ostrożność w przypadku globalnej aktywacji. Serwer WWW może wówczas uruchomić się, podczas gdy usługa pocztowa, agent lub aplikacja nie będą w stanie uzyskać dostępu do algorytmu znajdującego się poza dostawcą FIPS. Ponadto nie każda aplikacja koniecznie ładuje tę samą konfigurację OpenSSL. Dlatego przed wdrożeniem tego trybu jako standardu operacyjnego należy przetestować go dla każdej usługi i każdej rzeczywistej ścieżki połączenia w odpowiednim środowisku testowym.

Zwykłe Zabezpieczenie TLS Należy to traktować oddzielnie: obsługiwane pakiety bibliotek, aktualne certyfikaty, odpowiednie protokoły minimalne oraz polityka TLS dostosowana do danej usługi są wymagane nawet bez FIPS. Z drugiej strony tryb FIPS nie zastępuje ani zarządzania certyfikatami, ani zarządzania poprawkami. Należy zatem zaplanować go jako odrębny projekt zapewnienia zgodności z przepisami, obejmujący zakresy odpowiedzialności, dokumentację i procedury awaryjne – a nie jako przełącznik zapewniający ogólnie bezpieczniejszą instalację.

Ustal model działania dla OpenSSL

Das Model operacyjny określa, kto monitoruje aktualizacje oraz z jakiej biblioteki faktycznie korzysta dana usługa. W przypadku pakietu dystrybucyjnego należy sprawdzić aktualny stan pakietu na podstawie oficjalnych informacji dostawcy dotyczących bezpieczeństwa, pakietów i cyklu życia. Dostępne źródła OpenSSL nie wskazują, w jaki sposób dana dystrybucja Linuksa udostępnia poprawki ani jak długo zapewnia wsparcie dla danego pakietu.

Migracja do OpenSSL 3.5 LTS Ma to sens, gdy potrzebna jest określona gałąź upstream, a operator jest odpowiedzialny za jej utrzymanie. OpenSSL w wersji 3.5 będzie obsługiwany do 8 kwietnia 2030 r. To, czy bardziej odpowiedni będzie pakiet dystrybucyjny, czy też własna wersja upstream, zależy natomiast od udokumentowanych kompetencji i wymagań systemu.

Kontenery mogą zawierać inną wersję biblioteki libcrypto niż system hosta; aktualizacja systemu hosta niekoniecznie zmienia tę wersję w czasie wykonywania. W przypadku kontenerów tworzonych samodzielnie dochodzą do tego ścieżki dostawców, jednostki usługowe i dynamiczne powiązania. Gwarancje dotyczące API i ABI w głównej gałęzi nie zastępują testów aplikacji, przestarzałych połączeń ENGINE ani zewnętrznych komponentów kryptograficznych.

Przed podjęciem decyzji należy zidentyfikować wszystkie procesy wykorzystujące zewnętrzne i wewnętrzne połączenia TLS. Należy je zaktualizować do obsługiwanej wersji za pośrednictwem odpowiedniego dostawcy oraz przetestować rzeczywiste ścieżki usług w środowisku testowym. Nieuniknione wyjątki należy ograniczyć do danej usługi i udokumentować, podając ryzyko, osobę odpowiedzialną oraz datę zakończenia.

Podczas wprowadzania zmian mających wpływ na wydajność należy monitorować nie tylko błędy TLS, ale także stan procesów, czasy odpowiedzi i zużycie pamięci. Ponowne uruchomienia i nieudane ponowne połączenia mogą powodować przejściowe skoki obciążenia. Artykuł na temat Obciążenie pamięci w jądrze systemu Linux pomaga odróżnić błędy kryptograficzne od sytuacji, w których występuje jednoczesne obciążenie zasobów.