TLS jest protokołem skomplikowanym i z tego powodu w ostatnich kilku latach w powszechnie używanych implementacjach TLS wykryto wiele błędów. Analizując znane obecnie scenariusze łamania zabezpieczeń SSL/TLS, można przypuszczać, że ich lista nie jest jeszcze zamknięta. Oto najważniejsze z nich.

1. Opublikowany w 1998 r. atak Daniela Bleichenbachera (http://www.cert.org/advisories/CA-1998-07.html ) wykorzystuje fakt, że serwer SSL sygnalizuje błąd w formatowaniu PKCS #1 (Public Key Cryptography Standard #1) klucza sesyjnego wysyłanego przez klienta do serwera. Wysyłając dużą liczbę takich pakietów z błędem formatowania wprowadzonym w odpowiedni sposób i jednocześnie obserwując odpowiedzi serwera, atakujący może odtworzyć klucz sesyjny innego użytkownika bit po bicie. Możliwość przeprowadzenia takiego ataku została w większości implementacji zablokowana w ten sposób, że błąd formatowania jest wykrywany, lecz nie jest sygnalizowany klientowi - serwer kontynuuje przetwarzanie otrzymanego klucza sesyjnego, tak jakby był on poprawny. Nie prowadzi to oczywiście do nawiązania poprawnej sesji, ale uniemożliwia atakującemu szybkie zweryfikowanie poprawności odgadywanego kolejnego bitu klucza.
2. W lipcu 2002 r. wykryto cztery błędy programistyczne w popularnej implementacji OpenSSL ( http://www.cert.org/advisories/CA-2002-23.html ). Wszystkie z nich powodowały przepełnienie bufora (buffer overrun) i umożliwiały zdalne wykonanie przygotowanego przez atakującego kodu (exploit) na serwerze korzystającym z OpenSSL. Dotyczyło to przede wszystkim serwerów Apache oraz usług udostępnianych za pośrednictwem SSL przy użyciu tzw. wrapperów protokołów, np. program stunnel. Błędy te można potraktować jako problem typowy dla aplikacji sieciowych, wymagający systematycznego śledzenia ogłoszeń o nowych dziurach i łatania aplikacji na serwerach produkcyjnych. Istotne może być to, że Apache jest najpopularniejszym serwerem WWW w Internecie, a z OpenSSL korzysta także kilka akceleratorów SSL. Nieco później - ale też w 2002 r. - pojawił się robak internetowy, rozmnażający się właśnie dzięki dziurze w OpenSSL (http://www.cert.org/advisories/CA-2002-23.html ).
3. W maju 2000 r. Mitja Kolsek ze Słowenii, zainspirowany wcześniejszymi uwagami Matthiasa Suenckena z Niemiec, odkrył subtelny, lecz brzemienny w skutki, błąd w implementacji SSL wbudowanej w przeglądarkę Netscape Navigator (http://www.cert.org/advisories/CA-2000-05.html ). Łącząc się z serwerem SSL po raz pierwszy, Navigator poprawnie weryfikował przedstawiony przez niego certyfikat X.509, m.in. pod kątem zgodności nazwy DNS z nazwą w certyfikacie. Błąd polegał na tym, że następne połączenia z tym adresem IP były już przez Navigatora buforowane i niejako z góry uznawane za poprawnie zweryfikowane. Autor zaprezentował realny scenariusz, który pozwalał na takie przekierowanie przeglądarki ofiary, by poufne dane zostały wysłane do serwera atakującego bez żadnych ostrzeżeń. Błąd ten został usunięty w wersji 4.73 Netscape Navigator. Jego powstanie pokazało jednak wyraźnie, że stosunkowo niewielka pomyłka w implementacji SSL w przeglądarce WWW może zniweczyć cały system zabezpieczeń oferowany przez infrastrukturę PKI.
4. Błędem podobnej klasy był odkryty miesiąc później (w czerwcu 2000 r.) błąd w przeglądarce Microsoft Internet Explorer (http://www.microsoft.com/technet/security/bulletin/ms00-039.asp ). Tutaj również zawiódł drobny element weryfikacji certyfikatu serwera, a konkretnie weryfikacja ścieżki certyfikacji. Explorer, sprawdzając kolejne certyfikaty w ścieżce (idąc od dołu, certyfikat serwera, a następnie certyfikaty kolejnych CA), nie sprawdzał, czy certyfikat CA jest w ogóle uprawniony do podpisywania innych certyfikatów (nie sprawdzał ww. flag basic constraints). Dzięki temu był możliwy stosunkowo prosty atak polegający na przekierowaniu klienta na podstawiony serwer, prezentujący wprawdzie poprawną nazwę domenową, lecz sfałszowany certyfikat. Ścieżka certyfikacji była więc poprawnie weryfikowana, mimo że CA drugiego stopnia przedstawiał się certyfikatem nie uprawniającym go do podpisywania czegokolwiek. Również i tutaj drobny na pozór błąd w przeglądarce pozwolił na obejście całego złożonego systemu zabezpieczeń PKI.
5. Rok później, w maju i czerwcu 2001 r., odkryto kolejne podobne błędy w Internet Explorerze (http://www.kb.cert.org/vuls/id/22482 ). W pierwszym przypadku ścieżka certyfikacji nie była w ogóle weryfikowana, jeżeli odwołanie do serwera SSL było umieszczone w tagu IFRAME lub IMG. W drugim (http://www.kb.cert.org/vuls/id/399087 ) ścieżka nie była weryfikowana wtedy, gdy funkcja sprawdzania ważności certyfikatu poprzez listy certyfikatów odwołanych CRL (Certificate Revocation List) była włączona. Jeśli więc sfałszowany certyfikat na tej liście nie figurował (a nie figurował, skoro był sfałszowany), to IE akceptował go bez sprawdzania zgodności nazwy ani legalności CA, który go wystawił.
6. W lutym 2003 r. międzynarodowy zespół Canvel, Hiltgen i Vaudenay opublikował pierwszy z tegorocznej serii ataków na implementację OpenSSL (http://www.openssl.org/news/secadv_20030219.txt ). Atak wykorzystywał fakt, że biblioteka sygnalizowała błąd odszyfrowania dla spreparowanego przez atakującego kryptogramu. Umożliwiał on zgadywanie krótkich bloków tekstu w powtarzanych wielokrotnie połączeniach SSL. Warunek ten spełniały np. hasła POP3 lub IMAP w szyfrowanych połączeniach programu pocztowego do serwera. Błąd naprawiono podobnie jak atak Bleichenbachera, usuwając sygnalizację błędu dającą atakującemu cząstkę informacji potrzebnej do odgadnięcia hasła.
7. W marcu 2003 r. opublikowano opis potencjalnie bardzo poważnego ataku autorstwa dwóch Amerykanów: Brumleya i Boneha (http://www.kb.cert.org/vuls/id/997481 ). Scenariusz ataku przewidywał odtworzenie prywatnego klucza RSA serwera za pomocą zgadywania kolejnych bitów i ich weryfikowanie za pomocą różnic w czasie wykonywania przez serwer deszyfrowania RSA na przysyłanych ciągach liczb. Skuteczność tego ataku jest nieco ograniczona ze względu na konieczność bardzo dokładnego mierzenia czasu odpowiedzi serwera, co przy połączeniach przez sieci rozległe jest trudne. Jednak po zestawieniu szybkiego łącza do serwera autorom udało się odtworzyć cały klucz prywatny serwera o długości 1024 bitów za pomocą ok. 350 tys. zapytań w czasie ok. 2 godz. Był to typowy błąd implementacji SSL, ponieważ ataki tego typu (timing attacks) na protokół RSA były znane znacznie wcześniej. Odpowiednie zabezpieczenie (tzw. RSA blinding) jest obecnie wbudowane w karty mikroprocesorowe, akceleratory sprzętowe, a także w większość implementacji programowych RSA, również OpenSSL. Co ciekawe, OpenSSL ma funkcję blindingu dla RSA, jednak nie była ona dotychczas włączana domyślnie. Ten sam problem dotyczył niektórych aplikacji korzystających z biblioteki BSAFE firmy RSA. Możliwość przeprowadzenia opisanego wyżej ataku ujrzała światło dzienne dopiero teraz, ponieważ uważano, że SSL nie jest podatny na timing attack. Wniosek z tego taki, że warto włączać dostępne zabezpieczenia nawet na wszelki wypadek, bo w przyszłości mogą pojawić się zupełnie nowe ataki.
8. W kwietniu 2003 r. trzej czescy kryptolodzy: Klima, Pokorny i Rosa opracowali nową odmianę ataku Bleichenbachera (http://www.kb.cert.org/vuls/id/888801 ), która, zamiast błędnego formatowania PKCS, wykorzystywała niepoprawny numer wersji w pakiecie SSL. Tak jak w poprzednim, w tym ataku komunikat serwera umożliwiał zweryfikowanie poprawności zgadywanego bitu klucza. Autorzy przedstawili także konkretne dane eksperymentalne - "wyciągnięcie" w ten sposób klucza sesyjnego z serwera SSL poprzez łącze Ethernet 100 Mb/s wymagało wykonania 13 mln zapytań i zajęło ok. 55 godz.

"Czeski" przypadek udowodnił, że nawet skomplikowany technicznie atak na protokół kryptograficzny może przynieść realne efekty - co prawda w określonych warunkach - ale jednak. Pośrednio pokazał także, jak ważne jest ciągłe monitorowanie serwerów produkcyjnych - odpowiednio skonfigurowany IDS lub wykwalifikowany administrator prawdopodobnie zauważyłby atak w tak znaczący sposób angażujący zasoby serwera.

Jedyną metodą na uniknięcie ataków umożliwianych przez nowo odkryte luki w zabezpieczeniach jest systematyczne uaktualnianie oprogramowania i nakładanie łat rekomendowanych przez producenta. Sprzętowe akceleratory, wbrew pozorom, są wewnątrz tworami w dużej mierze programowymi - tylko nieliczne spośród nich rzeczywiście zawierają układy ASIC dedykowane do obsługi wymagających protokołów. Również i w tym przypadku nie da się więc uciec od problemów związanych nieodłącznie z aktualizowaniem oprogramowania.