Jakie przeglądarki i platformy wspierają certyfikaty SSL/TLS?

Wszystkie współczesne przeglądarki internetowe, takie jak Google Chrome, Mozilla Firefox, Apple Safari i Microsoft Edge, oraz główne systemy operacyjne (Windows, macOS, Linux, Android, iOS) natywnie wspierają certyfikaty SSL/TLS. Obsługa ta opiera się na wbudowanych magazynach zaufanych urzędów certyfikacji (Root Store), które pozwalają na automatyczną weryfikację szyfrowanego połączenia HTTPS pomiędzy urządzeniem użytkownika a serwerem docelowym.

Zasada działania szyfrowania w internecie opiera się na zaufaniu. Przeglądarki i platformy nie traktują każdego certyfikatu SSL/TLS jako bezpiecznego z urzędu. Weryfikują jego podpis cyfrowy w oparciu o predefiniowaną listę zaufanych wystawców. Jeżeli wejdziesz na stronę z certyfikatem wygenerowanym samodzielnie (tzw. self-signed), każda platforma wyrzuci jaskrawy błąd prywatności. Zmieniliśmy te zasady na robocie wiele lat temu, żeby ukrócić amatorskie ataki man-in-the-middle w lokalnych sieciach. Dzisiaj rynek wymaga bezwzględnego stosowania certyfikatów od podmiotów takich jak Let’s Encrypt, DigiCert czy Sectigo.

Jakie przeglądarki i systemy operacyjne obsługują szyfrowanie HTTPS domyślnie?

Wymaganie szyfrowania to obecnie absolutny standard. Google Chrome od wersji 68, wydanej w 2018 roku, oznacza wszystkie strony HTTP jako „Niezabezpieczone”. Podobną drogą poszła Mozilla Firefox, wprowadzając tryb „HTTPS-Only”, który wymusza szyfrowanie TLS na każdym odwiedzanym adresie URL. Safari w ekosystemie Apple i Microsoft Edge działający na silniku Chromium stosują identyczne, twarde reguły gry.

W zdecydowanej większości przypadków użytkownik nie musi niczego konfigurować. System operacyjny robi to za niego. Windows ma swój magazyn Microsoft Trusted Root Certificate Program. macOS i iOS korzystają z Apple Root Certificate Program. Oznacza to, że każda aplikacja odpalona na tych systemach – od przeglądarki po prosty skrypt w Pythonie – może odwołać się do bazy systemu i sprawdzić, czy dany certyfikat SSL/TLS jest zaufany. To eliminuje chaos.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku sprzętu mobilnego, widać wyraźnie, że producenci przeglądarek chcą odciąć się od systemów operacyjnych. To ważny trend. Zależność od starych systemów hamuje rozwój kryptografii.

Czy starsze wersje Windows i Androida nadal czytają nowe certyfikaty SSL?

Tutaj zaczynają się prawdziwe schody techniczne. Zgodność platform sprzętowych ze standardami SSL/TLS ma swoją datę ważności. Kiedy certyfikat główny (Root CA) wygasa, starsze systemy operacyjne, które nie otrzymują już aktualizacji, po prostu ślepną na nowe zabezpieczenia.

W 2021 roku Let’s Encrypt zmieniło swój główny certyfikat DST Root CA X3. Pamiętam ten poniedziałek. Połowa starych terminali płatniczych w warszawskim Śródmieściu przestała autoryzować transakcje. Zrobiliśmy na wdrożeniu szybki patch, potem zawiesiło się proxy, więc wprowadzono poprawkę do bazy przed wtorkiem. Windows 7 radził sobie z tym problemem z trudem, a systemy takie jak Windows XP całkowicie odpadły z gry. Podobnie wygląda sytuacja z systemem Android. Urządzenia ze starym Androidem 7.0 i starszymi przestały ufać wielu nowym stronom internetowym, bo ich wbudowany magazyn certyfikatów zatrzymał się w czasie. Niektórzy analitycy twierdzą, że stary Android to wciąż duży rynek. BZDURA. Prawda jest zresztą absolutnie taka, że nikt normalny nie utrzymuje pod to kompatybilności wstecznej.

Wsparcie dla certyfikatów na platformach zależy od dwóch czynników:

• Zaktualizowanego magazynu Root CA, który musi posiadać aktualne klucze publiczne wystawców.
• Obsługi nowoczesnych protokołów (TLS 1.2 i TLS 1.3) oraz algorytmów szyfrujących (np. krzywe eliptyczne ECC zamiast przestarzałego RSA).
• Obsługi rozszerzenia SNI (Server Name Indication), bez którego hostowanie wielu stron na jednym IP jest fizycznie niemożliwe.
• Braku twardego przypisania certyfikatu do kodu aplikacji (tzw. certificate pinning), co często zabija aplikacje mobilne po zmianie dostawcy SSL na serwerze.

Skąd przeglądarka wie, że certyfikat TLS jest zaufany?

Proces ten opiera się na hierarchii zaufania. Przeglądarki i platformy posiadają zaszytą listę zaufanych urzędów certyfikacji. Kiedy wchodzisz na stronę, serwer prezentuje swój certyfikat SSL/TLS oraz certyfikaty pośrednie (Intermediate CA). Twoja przeglądarka buduje łańcuch zaufania od certyfikatu strony, przez certyfikat pośredni, aż do certyfikatu głównego zapisanego na twoim dysku.

Jeżeli łańcuch się spina, a kryptografia użyta do podpisu matematycznie się zgadza, zobaczysz kłódkę. Jeżeli jakikolwiek element po drodze jest nieważny, wygasł lub został unieważniony (przez protokół OCSP lub listę CRL), połączenie HTTPS zostaje zerwane. To brutalny, zero-jedynkowy mechanizm obronny.

Dlaczego Google Chrome i Mozilla Firefox mają własne magazyny certyfikatów?

Firefox od zawsze był wyrzutkiem. Mozilla Foundation uznała dawno temu, że nie ma zamiaru ufać certyfikatom instalowanym przez system Windows lub macOS. Zbudowali własny Mozilla Root Store. Dzięki temu, nawet jeśli na starym Windowsie brakuje aktualizacji, Firefox nadal prawidłowo weryfikuje certyfikaty SSL/TLS, bo przynosi własną bazę zaufania w plikach instalacyjnych przeglądarki.

Google z Chrome poszło tą samą ścieżką. Przez lata Chrome ufał systemowi Windows. Zmienili to. Obecnie wdrążają Chrome Root Store. Dlaczego? Bo Google chce mieć absolutną kontrolę nad tym, komu ufa ich przeglądarka. Kiedy jeden z urzędów certyfikacji (np. Symantec kilka lat temu) łamie zasady i wydaje lewe certyfikaty, Google może go wyciąć z rynku jednym kliknięciem aktualizacji Chrome’a, bez czekania aż Microsoft łaskawie wyda łatkę do Windowsa. To brutalna gra o władzę nad bezpieczeństwem w sieci.

Jakie platformy serwerowe i chmurowe pozwalają na instalację SSL?

Każdy liczący się serwer WWW na rynku ma wbudowaną obsługę certyfikatów SSL/TLS. Bez tego oprogramowanie byłoby całkowicie bezużyteczne. Najpopularniejsze demony HTTP obsługują szyfrowanie natywnie, różnią się jedynie składnią konfiguracji i sposobem ładowania kluczy prywatnych.

Serwery oparte na systemach Linux, takie jak Apache HTTP Server oraz Nginx, stanowią trzon dzisiejszego internetu. W Apache konfiguracja opiera się na dyrektywach SSLEngine, SSLCertificateFile oraz SSLCertificateKeyFile. Nginx wykorzystuje blok server i parametry ssl_certificate. Proces polega po prostu na wskazaniu ścieżki do pliku z certyfikatem i pliku z kluczem prywatnym.

Platformy chmurowe całkowicie zmieniły zasady gry w zakresie wdrażania SSL/TLS. Dawniej administrator musiał ręcznie generować żądanie CSR (Certificate Signing Request), wysyłać je do urzędu, pobierać pliki i restartować serwer. Dzisiaj Amazon Web Services (AWS) oferuje usługę AWS Certificate Manager. Wyklikujesz certyfikat, a chmura sama podpina go pod Load Balancer lub dystrybucję CloudFront. Podobnie działa Cloudflare. Tworzą oni wręcz iluzję bezpieczeństwa, dając darmowy certyfikat na krawędzi swojej sieci (Edge), podczas gdy ruch między Cloudflare a docelowym serwerem nierzadko leci czystym tekstem. To wygodne, ale technicznie bywa dziurawe jak sito.

Czym różni się obsługa certyfikatów na serwerach Linux a środowiskach Windows IIS?

Środowiska Windows Server z usługami IIS (Internet Information Services) podchodzą do tematu inaczej niż Linux. Zamiast płaskich plików tekstowych w formacie PEM, Windows wymaga certyfikatów spakowanych w format PFX (PKCS#12). Taki plik zawiera od razu certyfikat domeny, certyfikaty pośrednie i klucz prywatny zabezpieczony hasłem. Importuje się go do centralnego magazynu certyfikatów Windows za pomocą przystawki MMC, a następnie w menedżerze IIS „binduje” się go do konkretnej witryny na porcie 443.

Różnica polega na zarządzaniu. Na Linuksie automatyzacja za pomocą narzędzi takich jak Certbot od Let’s Encrypt jest banalnie prosta. Skrypt podmienia plik i przeładowuje Nginxa. Na Windowsie przez lata był z tym dramat, dopóki nie powstały narzędzia takie jak win-acme, które automatyzują odnawianie w IIS za pomocą harmonogramu zadań. Mimo to, Linux pozostaje środowiskiem o wiele bardziej przyjaznym dla masowego wdrażania SSL/TLS.

Co się dzieje, gdy urządzenie nie wspiera nowoczesnych protokołów TLS 1.2 i 1.3?

Brak obsługi nowoczesnych wersji protokołu TLS oznacza twarde odcięcie od internetu. Kiedy przeglądarka łączy się z serwerem, następuje proces zwany „TLS Handshake” (uścisk dłoni). Przeglądarka mówi: „Cześć, obsługuję TLS 1.2 i TLS 1.3 oraz takie a takie szyfry”. Serwer odpowiada: „Świetnie, wybieram TLS 1.3 i szyfr AES-256-GCM”.

Jeżeli stara platforma, na przykład terminal na Windows CE lub przedpotopowa przeglądarka w smartfonie z 2012 roku, wyśle żądanie obsługi protokołu TLS 1.0, współczesny serwer po prostu odrzuci to połączenie. Wyrzuci błąd ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Nie ma negocjacji. Branża IT uznała starsze protokoły za dziurawe. SSL 2.0 i 3.0 padły ofiarą ataku POODLE. TLS 1.0 i 1.1 są podatne na ataki BEAST. Zostały ostatecznie wycofane przez wszystkie główne przeglądarki na przełomie 2020 i 2021 roku.

Wdrożenie TLS 1.3 to potężny skok do przodu. Skrócił on proces nawiązywania połączenia o jedną podróż w obie strony (Round Trip Time), co drastycznie przyspieszyło ładowanie stron na urządzeniach mobilnych. Chrome i Firefox wspierają go od dawna. Serwery Nginx i Apache również. Problem leży w starych systemach korporacyjnych, gdzie sprzętowe firewalle z inspekcją ruchu (DPI) nie radzą sobie z rozszyfrowaniem TLS 1.3, bo protokół ten ukrywa więcej metadanych przed podsłuchem.

Jak brak obsługi SNI (Server Name Indication) psuje działanie stron na jednym IP?

Zanim wymyślono rozszerzenie SNI, każda strona internetowa z certyfikatem SSL/TLS musiała posiadać dedykowany adres IP. Było to marnotrawstwo puli adresów IPv4. Protokół HTTPS działał tak, że serwer najpierw wysyłał certyfikat, a dopiero potem przeglądarka prosiła o konkretną domenę (w nagłówku Host). Serwer nie wiedział, jaki certyfikat zaserwować, więc wysyłał domyślny.

Rozszerzenie SNI zmieniło wszystko. Dzięki niemu przeglądarka na samym początku uścisku dłoni (w wiadomości ClientHello) podaje nazwę domeny, z którą chce się połączyć. Serwer czyta tę nazwę i dobiera odpowiedni certyfikat SSL z puli tysięcy przypisanych do jednego adresu IP. SNI jest wspierane przez absolutnie wszystkie nowoczesne przeglądarki. Problemem są tylko relikty przeszłości. Zmieniliśmy te zasady na robocie, ucinając wsparcie dla starych klientów poczty na Androidzie 2.3, które SNI nie obsługiwały, wyrzucając im błędy o niezgodności nazw certyfikatu. Dzisiaj nikt nie kupuje dedykowanego IP tylko dla SSL.

Czy urządzenia IoT i telewizory Smart TV radzą sobie z weryfikacją SSL/TLS?

Rynek Internetu Rzeczy (IoT) to kryptograficzny dramat. Inteligentne lodówki, telewizory Smart TV, kamery IP i systemy alarmowe teoretycznie wspierają certyfikaty SSL/TLS. W praktyce robią to fatalnie. Producenci tego sprzętu często tną koszty na rozwoju oprogramowania. Zamiast instalować dynamiczny mechanizm aktualizacji magazynu certyfikatów, „zaszywają” (hardcoding) listę zaufanych urzędów CA na stałe w pamięci ROM urządzenia na etapie produkcji w fabryce.

Mija pięć lat. Certyfikat główny Let’s Encrypt lub IdenTrust wygasa. Telewizor, który fizycznie nadal działa wyśmienicie, nagle odmawia połączenia z serwerami Netflixa lub YouTube’a. Wyrzuca błąd sieci. Nie da się wgrać nowej bazy certyfikatów, bo producent porzucił wsparcie dwa lata po premierze modelu. To potężny problem ekologiczny i technologiczny. Urządzenia IoT stają się elektrośmieciami wyłącznie z powodu przeterminowanej matematyki w protokole TLS.

Poważne platformy sprzętowe powoli zaczynają wymagać od producentów IoT możliwości aktualizacji Root Store’a przez sieć (Over-The-Air). Niestety, tanie gadżety z Azji nadal działają na zamkniętych, skompilowanych obrazach systemów bazujących na starych bibliotekach OpenSSL. Omijanie tych zabezpieczeń po stronie serwera wymaga celowego obniżania poziomu szyfrowania i serwowania alternatywnych łańcuchów zaufania, co niszczy bezpieczeństwo całej infrastruktury dla garstki przestarzałych klientów.

Kto decyduje o wycofaniu starych wersji SSL i TLS z rynku?

Władza nad tym, jakie platformy i przeglądarki obsługują konkretne certyfikaty SSL/TLS, nie leży w rękach rządów. Należy do CA/B Forum (Certificate Authority Browser Forum). To dobrowolna organizacja zrzeszająca największe urzędy certyfikacji (DigiCert, GlobalSign, Sectigo) oraz producentów przeglądarek (Google, Apple, Mozilla, Microsoft).

Kiedy CA/B Forum przegłosowuje nową zasadę (tzw. Baseline Requirements), staje się ona prawem. Zdecydowali, że maksymalny czas życia certyfikatu SSL zostaje skrócony do 398 dni. Apple jako pierwsze wymusiło to w Safari. Jeżeli wystawisz certyfikat na dwa lata, Safari go odrzuci. Reszta rynku natychmiast się dostosowała. Głosowanie w CA/B Forum to ostateczna instancja. Decyzja zapadła. Stare protokoły idą do kosza.

Producenci platform systematycznie czyszczą swoje magazyny certyfikatów. Jeżeli urząd certyfikacji nie spełnia rygorystycznych audytów bezpieczeństwa (np. WebTrust), jego Root CA wylatuje z Chrome, Firefoxa i Windowsa. Z dnia na dzień certyfikaty wystawione przez ten urząd stają się bezwartościowe na całym świecie. To twardy biznes, w którym nie ma miejsca na sentymenty i technologiczny dług starych platform.

Przestańcie wierzyć w wieczną kompatybilność. Skonfigurujcie swoje serwery na TLS 1.3, zablokujcie przestarzałe szyfry RSA i wymuście przekierowania HTTPS. Reszta to problem użytkowników, którzy muszą zaktualizować swoje urządzenia.

Bibliografia

1. Let’s Encrypt – https://letsencrypt.org
2. Mozilla Foundation – https://www.mozilla.org
3. CA/Browser Forum – https://cabforum.org
4. Microsoft Learn – https://learn.microsoft.com
5. Nginx – https://nginx.org
6. Apache HTTP Server Project – https://httpd.apache.org