TLS jest następcą SSL 3.0, TLS to protokół zapewniający szyfrowanie danych i integralność między kanałami komunikacji. SSL 3.0 służy jako baza dla TLS 1.0.
SSL czy TLS. Co jest lepsze?
Wierzymy, że TLS 1.0 jest następcą SSL 3.0. Jak wiemy, SSL 3.0 jest bardzo stare i podatne na ataki, takie jak POODLE, BEAST i inne, które sprawiły, że SSL 3.0 stał się bezużyteczny jako protokół bezpieczeństwa.
Z powodu ataku POODLE, SSL v3 jest całkowicie wyłączany na stronach internetowych na całym świecie.
Następnie atak BEAST całkowicie łamie strony internetowe działające na starszych protokołach SSL v3.0 i TLS v1.0.
Niestety nadal niektóre strony internetowe nie używają TLS. Możesz sprawdzić konfigurację swojej strony za pomocą np. analizatora Comodo SSL.
Protokół uzgadniania TLS
Gdy klient i serwer TLS po raz pierwszy zaczynają komunikować się, uzgadniają wersję protokołu, wybierają algorytmy kryptograficzne, opcjonalnie uwierzytelniają się nawzajem i używają technik szyfrowania kluczem publicznym do generowania wspólnych tajnych informacji.
Protokół uzgadniania TLS obejmuje następujące kroki:
- Wymiana wiadomości hello, aby uzgodnić algorytmy, wymieniać losowe wartości i sprawdzać wznowienie sesji.
- Zamiana niezbędnych parametrów kryptograficznych, aby umożliwić klientowi i serwerowi uzgodnienie premaster secret.
- Wymiana certyfikatów i informacji kryptograficznych, aby umożliwić klientowi i serwerowi ich uwierzytelnienie.
- Wygenerowanie master secret z premaster secret i wymiana losowych wartości.
- Dostarczenie parametrów bezpieczeństwa do warstwy typu Record.
- Zezwolenie klientowi i serwerowi na sprawdzenie, czy ich partner równorzędny obliczył te same parametry zabezpieczeń i czy uzgadnianie nastąpiło bez ingerencji osoby atakującej.
Powiadomienia protokołu TLS i SSL
W przypadku napotkania jakiegokolwiek problemu w połączeniu, którakolwiek ze stron, która wykryje problem, wyświetli komunikat ostrzegawczy.
Opisy alertów SSL
Close_Notify
Ta wiadomość informuje odbiorcę, że nadawca nie będzie wysyłać więcej wiadomości w tym połączeniu.
Unexpected_message
Otrzymano niespodziewaną wiadomość. Ten alert jest zawsze fatalny i nigdy nie powinien się wyświetlić w komunikacji w poprawnej implementacji.
Bad_record_mac
Ten alert jest zwracany, jeśli odebrany zostanie rekord z nieprawidłowym adresem MAC. Ten komunikat zostanie zwrócony, jeśli alert zostanie wysłany, ponieważ tekst TLSCiphertext został odszyfrowany w nieprawidłowy sposób: albo nie była to wielokrotność długości bloku, albo jego wartości wypełnienia, gdy są zaznaczone, były nieprawidłowe.
Decryption_failed_RESERVED
Ten alert był używany w niektórych wcześniejszych wersjach TLS i mógł zezwolić na niektóre ataki w trybie CBC.
Record_overflow
Otrzymano rekord TLSCiphertext o długości przekraczającej 2^14+2048 bajtów lub rekord odszyfrowany do rekordu TLSCompressed o długości większej niż 2^14+1024 bajty.
Decompression_failure
Funkcja dekompresji otrzymała niewłaściwe dane wejściowe (np. dane, które rozszerzyłyby się do nadmiernej długości). Ten komunikat jest zawsze fatalny i nigdy nie powinien się pojawić w komunikacji w poprawnej implementacji.
Handshake_failure
Odebranie komunikatu ostrzegawczego handshake_failure wskazuje, że nadawca nie był w stanie wynegocjować akceptowalnego zestawu parametrów bezpieczeństwa, biorąc pod uwagę dostępne opcje. To jest błąd krytyczny.
No_certificate_RESERVED
Ten alert był używany w SSLv3, ale nie w żadnej wersji TLS. NIE MOŻE być wysyłany przez kompatybilne implementacje.
Bad_certificate
Certyfikat był uszkodzony, zawierał podpisy, które nie zostały poprawnie zweryfikowane itp.
Unsupported_certificate
Certyfikat był nieobsługiwanego typu.
Certificate_revoked
Certyfikat został unieważniony przez osobę podpisującą.
Dodatkowe opisy alertów TLS
Certificate_expired
Certyfikat wygasł lub jest obecnie nieważny.
Certificate_unknown
Podczas przetwarzania certyfikatu pojawił się inny (nieokreślony) problem, przez co stał się on nie do zaakceptowania.
Illegal_parameter
Pole w handshake było poza zakresem lub było niespójne z innymi polami. Ta wiadomość jest zawsze fatalna.
Unknown_ca
Otrzymano prawidłowy łańcuch certyfikatów lub łańcuch częściowy, ale certyfikat nie został zaakceptowany, ponieważ nie można znaleźć certyfikatu urzędu certyfikacji lub dopasować go do znanego, zaufanego urzędu certyfikacji. Ta wiadomość jest zawsze fatalna.
Access_denied
Otrzymano ważny certyfikat, ale po zastosowaniu kontroli dostępu nadawca zdecydował się nie kontynuować negocjacji. Ta wiadomość jest zawsze fatalna.
Decode_error
Nie można zdekodować wiadomości, ponieważ niektóre pola były poza określonym zakresem lub długość wiadomości była nieprawidłowa. Ten komunikat jest zawsze krytyczny i nigdy nie powinien pojawić się w komunikacji w poprawnej implementacji. (z wyjątkiem sytuacji, gdy komunikaty zostały uszkodzone w sieci).
Decrypt_error
Operacja kryptograficzna uzgadniania nie powiodła się, w tym nie można poprawnie zweryfikować podpisu lub zweryfikować wiadomości o zakończeniu. Ta wiadomość jest zawsze krytyczna.
Export_restriction_RESERVED
Ten alert był używany w niektórych wcześniejszych wersjach TLS. NIE MOŻE być wysyłany przez zgodne implementacje.
Protocol_version
Wersja protokołu, którą klient próbował wynegocjować, jest rozpoznawana, ale nie jest obsługiwana. (Na przykład ze względów bezpieczeństwa można unikać starych wersji protokołów.) Ten komunikat jest zawsze krytyczny.
Insufficient_security
Zwracany zamiast handshake_failure, gdy negocjacja nie powiodła się, ponieważ serwer wymaga szyfrów bezpieczniejszych niż te obsługiwane przez klienta. Ta wiadomość jest zawsze fatalna.
Internal_error
Internal_error niezwiązany z peerem lub poprawnością protokołu (np. błąd alokacji pamięci) uniemożliwia kontynuację. Ta wiadomość jest zawsze fatalna.
User_canceled
Ten handshake jest anulowany z jakiegoś powodu niezwiązanego z awarią protokołu. Jeśli użytkownik anuluje operację po zakończeniu uzgadniania, bardziej odpowiednie jest zamknięcie połączenia przez wysłanie close_notify. Po tym alercie powinien nastąpić close_notify. Ten komunikat jest na ogół ostrzeżeniem.
No_renegotiation
Wysłane przez klienta w odpowiedzi na żądanie hello lub przez serwer w odpowiedzi na hello klienta po wstępnym uzgadnianiu Każde z nich normalnie prowadziłoby do renegocjacji; jeśli nie jest to właściwe, odbiorca powinien odpowiedzieć, wysyłając ten alert. W tym momencie pierwotny zleceniodawca może zdecydować, czy kontynuować połączenie.
Jednym z przypadków, w których byłoby to właściwe, jest sytuacja, w której serwer uruchomił proces w celu zaspokojenia żądania; proces może otrzymać parametry bezpieczeństwa (długość klucza, uwierzytelnianie itp.) podczas uruchamiania i może być ciężko, aby zakomunikować zmiany tych parametrów po tym zdarzeniu. Ta wiadomość jest zawsze ostrzeżeniem.
Unsupported_extension
Wysyłane przez klientów, którzy otrzymują rozszerzone hello serwera zawierające rozszerzenie, którego nie umieścili w odpowiednim hello klienta. Ta wiadomość jest zawsze fatalna.
Kompatybilność z TLS i SSL
Ponieważ istnieją różne wersje TLS (1.0, 1.1, 1.2 i wszelkie przyszłe wersje) oraz SSL (2.0 i 3.0), oznacza to, że potrzebna jest negocjacja, jaką wersję protokołu użyć do komunikacji.
Protokół TLS zapewnia wbudowany mechanizm negocjacji wersji, aby nie przeszkadzać innym komponentom protokołu złożonością wyboru wersji.
Klient TLS 1.2, który chce negocjować z takimi starszymi serwerami, wyśle normalny ClientHello TLS 1.2 zawierający { 3, 3 } (TLS 1.2) w ClientHello.client_version.
Jeśli serwer nie obsługuje tej wersji, odpowie ServerHello zawierający starszy numer wersji. Gdy klient wyrazi zgodę na korzystanie z tej wersji, negocjacje będą przebiegać zgodnie z negocjowanym protokołem
Kiedy serwer TLS otrzyma ClientHello zawierający numer wersji większy niż najwyższa wersja obsługiwana przez serwer, MUSI odpowiedzieć zgodnie z najwyższą wersją obsługiwaną przez serwer.
Na przykład, jeśli serwer obsługuje TLS 1.0, 1.1 i 1.2, a wersja_klienta to TLS 1.0, serwer będzie kontynuował TLS 1.0 ServerHello. Jeśli serwer obsługuje (lub chce używać) tylko wersje większe niż wersja_klienta, MUSI wysłać komunikat ostrzegawczy „protocol_version” i zamknąć połączenie.
Zawsze, gdy klient zna już najwyższą wersję protokołu znaną serwerowi (na przykład podczas wznawiania sesji), POWINIEN zainicjować połączenie w tym natywnym protokole.
