Zagadnienia związane z naruszeniem bezpieczeństwa SSL/TLS można podzielić na następujące grupy: naruszenia bezpieczeństwa spowodowane problemami z certyfikatami lub konfiguracją, wykorzystanie słabości protokołu, luki w bezpieczeństwie na poziomie aplikacji oraz problemy z zaufaniem do PKI.

Aplikacje chronione za pomocą SSL/TLS wymagają do swojej ochrony poprawnie wystawionego certyfikatu. Jeśli certyfikat nie obejmuje prefiksu lub obejmuje tylko niektóre z nich, strona www.przyklad.pl może być poprawnie identyfikowana, ale na przykład serwer2.przyklad.pl - już nie. Jeśli strona korzysta z hotlinkowanych obiektów lub linków do zawartości z innego serwera, certyfikat powinien obejmować szyfrowane połączenie także do drugiego serwera, włącznie z jego prefiksem. Niekiedy problem może dotyczyć alternatywnych nazw danego serwisu, a także stron, do których kierowani są niektórzy użytkownicy. Jest to poważna luka, gdyż według firmy Qualsys, aż 61,4% badanych certyfikatów stron nie pokrywa poprawnie głównej nazwy domeny lub nie obsługuje w ogóle alternatywnych nazw domen.

Za słaby jest ten klucz

Istotę zabezpieczeń SSL/TLS stanowi prywatny klucz, który jest wykorzystywany w procesie ustanawiania bezpiecznego szyfrowanego połączenia. Biorąc pod uwagę wydajność dostępnych komputerów, każdy klucz krótszy niż 1024 bity jest uznawany za słaby i musi być natychmiast wycofany, klucze 1024-bitowe również powinny być wycofywane w najbliższej przyszłości. Sprawa jest poważna, gdyż klucze o długości 512 bitów można złamać za pomocą niewielkiego klastra konsol Playstation lub kart Nvidia GPU. Z kolei klucze 2048 bitów są uznawane za silne i nieprędko będą złamane, biorąc pod uwagę planowany wzrost wydajności obliczeniowej procesorów. Na szczęście słabe klucze stanowią niewielki odsetek ogółu kluczy chroniących serwisy.

Zerwany łańcuch

Aby uwierzytelnienie było poprawne, niezbędny jest poprawnie zrealizowany łańcuch zaufania certyfikatów. Jeśli tutaj wystąpi błąd, umożliwi on napastnikom przeprowadzenie ataku pośrednictwa (man in the middle), ponadto samo bezpieczeństwo serwisu pozostaje pod znakiem zapytania. Obecnie blisko 11% badanych serwisów ma zerwane łańcuchy certyfikatów, przy czym liczono te, które takiego łańcucha wymagają. Jest to problem, z którym łatwo można sobie poradzić, zamawiając certyfikat u dobrego dostawcy i ściśle przestrzegając procedury jego wdrożenia. Z kolei problemy z mieszaną zawartością należy rozwiązać, wdrażając szyfrowanie całej zawartości - obecnie SSL nie jest dużym obciążeniem dla serwera webowego.

Zła konfiguracja

Najpoważniejszym problemem związanym z błędami w konfiguracji serwera jest wykorzystanie SSL 2.0 oraz używanie słabych algorytmów szyfrujących.

SSL 2.0 zawiera wiele błędów, z których warto wymienić: użycie identycznych kluczy do uwierzytelnienia i szyfrowania, słabą konstrukcję MAC, brak zabezpieczeń procesu uzgadniania komunikacji i słabą ochronę przed innymi atakami pośrednictwa. O ile większość serwerów obsługuje nowsze wersje, problem może dotyczyć przeglądarki Internet Explorer 6.0. W Polsce liczba użytkowników tej przeglądarki jest coraz mniejsza, problemy mogą sprawiać niektóre aplikacje firmowe, wykorzystujące technologie własnościowe Microsoftu. Takich aplikacji nie wolno udostępniać publicznie, gdyż SSL 2.0 nie zapewnia bezpieczeństwa transmisji ani poprawnego uwierzytelnienia.

Ponad połowa badanych serwerów nadal wspiera SSL 2.0, nawet jeśli nowoczesne przeglądarki z tego protokołu nie korzystają.

Słabe szyfrowanie

Standardem szyfrowania jest stosowanie kluczy o długości co najmniej 128 bitów i taką długość klucza obsługuje niemal każdy badany serwer (99,99%). Dłuższe klucze, 256 bitów, mogą być użyte w około 61% badanych serwerów, co oznacza, że nowoczesne przeglądarki będą w stanie zapewnić mocne szyfrowanie w każdym przypadku. Mimo wszystko nadal aż 58% serwerów wspiera szyfrowanie słabsze niż 128 bitów - a takich konfiguracji nie powinno być w ogóle. Obejmują one konfiguracje oznaczone jako "EXPORT" lub 64-bitowy DES.

Z kolei luka w TLS 1.0 umożliwia stopniowe pozyskiwanie szyfrowanej informacji (atak BEAST). Tymczasową radą jest wymuszenie algorytmu RC4 (dyrektywami SSLHonorCipherOrder On, SSLCipherSuite RC4-SHA:HIGH: !ADH).

Innym problemem, także związanym z szyfrowaniem, jest złe oznaczenie cookies używanych do uwierzytelnienia - zaledwie 15% badanych stron prawidłowo oznacza cookies jako SSL-only. Cookies bez takiego oznaczenia można ukraść w ataku pośrednictwa.

Luka w protokole

Poważna luka związana z renegocjacją SSL/TLS została odkryta w 2009 r. niezależnie przez dwóch badaczy (Marsha Raya i Martina Rexa). Zanim została załatana, umożliwiała przenoszenie wielu niezależnych strumieni SSL/TLS w jednym połączeniu TCP. Zatem protokoły wyższych warstw widziały tylko jedną konwersację i możliwy był atak pośrednictwa polegający na rozpoczęciu połączenia przez napastnika i zleceniu ofierze, by to połączenie dokończyła. Wykorzystanie ataku Cross-Site Request Forgery umożliwia przejęcie sesji, a przekierowanie na inną stronę ułatwi kradzież cookie, a w ten sposób - przejęcie uprawnień użytkownika.

Jest to poważna luka i dotyczy wielu serwerów - co czwarta badana strona WWW obsługuje niebezpieczną renegocjację sesji (26%), ponad połowa (52%) jedynie bezpieczną, niecałe 20% nie obsługuje renegocjacji w ogóle. Aby usunąć tę podatność, należy dokonać aktualizacji oprogramowania, gdyż większość dostawców obsługuje obecnie bezpieczny tryb RFC 5746. Jeśli jest to niemożliwe, należy wyłączyć renegocjację inicjowaną przez klienta.

Bezpieczeństwo szyfrowanej transmisji było jednym z tematów prelekcji na konferencji RSA Conference 2011 Europe.