Najczęstsze błędy w konfiguracji SSL

Nowy dokument ma status szkicu (draft) i jest opublikowany pod nazwą draft-agl-tls-oppractices-00. Jego celem jest udokumentowanie złych praktyk w konfiguracji serwerów SSL (Secure Sockets Layer) spotykanych w Internecie. Skutki tych błędów sa dwojakie - po pierwsze, osłabiają bezpieczeństwo. Po drugie powodują one problemy z interoperacyjnością, czyli na przykład sytuacje, w których klient nie może się połączyć z serwerem SSL np. ze względu na niezgodność protokołów. Takie sytuacje frustrują użytkownika i skutkują na przykład koniecznością oferowania połączeń nieszyfrowanych przez usługodawcę.

Niezgodność wersji protokołów

Protokół SSL ewoluował od 1994 roku i pierwsze trzy jego wersje były w całości opracowane przez firmę Netscape. Niewątpliwie najbardziej rozpowszechniony jest protokół SSL 3.0, opracowany oryginalnie w 1996 roku. W 1999 roku protokół SSL został przekazany do IETF, który opublikował nieznacznie zmodyfikowaną jego wersję jako TLS (Transport Layer Security). Protokół TLS 1.0 ma już więc prawie 12 lat i wydawałoby się, że obsługiwać go będą praktycznie wszyscy klienci a żaden serwer nie będzie miał problemów z jego obsługą (a w międzyczasie powstały jeszcze wersje TLS 1.1 i 1.2). Niestety, w praktyce okazuje się, że ok. 3% odrzuca klientów łączących się po protokole TLS 1.0.

Zobacz również:

• Wyjaśniamy czym jest SD-WAN i jakie są zalety tego rozwiązania

To nie jedyny problem - poza odrzucaniem protokołu TLS 1.0 niektóre serwery nie tolerują także jego nowszych wersji, odrzucają jakiekolwiek rozszerzenia a także - co najciekawsze - odrzucają połączenia od klientów wyrażających gotowość włączenia kompresji wewnątrz kanału TLS. Wiele programów klienckich, po odrzuceniu przez serwer propozycji połączenia (Client Hello) po TLS, wykona drugą próbę oferując niższą wersję protokołu, a także z wyłączonymi rozszerzeniami (np. kompresją). Niestety, zmiana protokołu na niższy (downgrade) może być także spowodowana przez zwykłe problemy z połączeniem, a jej skutkiem może być nieprawidłowe uwierzytelnienie serwera.

Sporo problemów serwerom TLS sprawia też obsługa licznych wersji protokołu, których numery są rozsiane w kolejnych pakietach wymienianych w trakcie negocjacji. Według autorów, ok. 30% serwerów w ogóle nie sprawdza wersji w pakiecie ClientKeyExchange a te, które to robią, sprawdzają ją w sposób niekonsekwentny lub niespójny (tylko ok. 0,6% konsekwentnie wymaga zgodności protokołu w kolejnych pakietach).

Luki w łańcuchu certyfikatów

W większości przypadków tylko serwer TLS uwierzytelnia się w stosunku do klienta za pomocą certyfikatu X.509, przygotowując zaufany kanał pod uwierzytelnienie klienta np. za pomocą hasła. Niestety informacje, które serwery wysyłają na etapie uwierzytelnienia certyfiatem często pozostawiają wiele do życzenia i niekiedy w ogóle uniemożliwiają jego przeprowadzenie. W takim przypadku klient zobaczy różne mniej lub bardziej zrozumiałe certyfikaty o błędach w certyfikacie serwera.

Poprawna prezentacja serwera powinna zawierać certyfikat głównego centrum certyfikacji (root CA), certyfikaty centrów pośrednich (intermediary) i właściwy certyfikat serwera, w tej kolejności. Do najczęstszych przypadków należy pomijanie certyfikatów pośrednich, przedstawianie ich w niewłaściwej kolejności lub - w drugą stronę - dołączanie do ścieżki certyfikatów nie mających nic wspólnego z daną ścieżką. Według autorów, którzy odnotowali serwery zwracające nawet 10 certyfikatów w ścieżce (typowo 2-3) jest to rezultat desperackiej próby wstrzelenia się "na ślepo" we właściwy zestaw certyfikatów.

Zamierzchłe wersje, stare szyfry

Szesnaście lat po publikacji informacji o błędach w protokole SSLv2 i stworzeniu jego poprawionej wersji (SSLv3) ponad 65% serwerów nadal oferuje połączenie po tej starej i dziurawej wersji protokołu. Co gorsza, spośród tych serwerów ponad 80% oferuje nadal celowo osłabione ("eksportowe") wersje algorytmów kryptograficznych, które przed 2000 rokiem były jedynymi, jakie można było firmom amerykańskim sprzedawać poza Stany Zjednoczone.

Komentarz - skąd te problemy?

Protokoły SSL i TLS mają historię bardzo typową dla innych protokołów internetowych - powstały w odpowiedzi na konkretny problem i zostały zaprojektowane w czasach gdy kryptografia cywilna nadal była dziedziną niszową. Ich autorzy wiele rozwiązań tworzyli intuicyjnie, nie dysponując żadnym aparatem formalnym ani do projektowania protokołu, ani nawet do pisania jego specyfikacji. Nie bez znaczenia była także pewna skłonność do "monumentalizmu", która skutkowała w latach 90-tych tworzeniem protokołów bardzo elastycznych i obsługujących wiele opcji (np. algorytmów kryptograficznych), co skutkowało ich ogromną złożonością.

Dokument można znaleźć na stronie Adama Langley:http://www.imperialviolet.org/2011/02/04/oppractices.html

Patrz też artykuł Po co nam SSL? (2007).