Referat z przedmiotu Witryny i Portale Internetowe

Referat z przedmiotu Witryny i Portale Internetowe

Protokół HTTPS
Adam Danecki
Informatyka
gr. 1.4
Wstęp, czyli małe co nieco, o HTTP
HTTP, czyli Hypertext Transfer Protocol, jest protokołem typu klient–serwer
poziomu warstwy aplikacji, służącym do przesyłania dokumentów tekstowych, jak i
danych binarnych. Dokumenty przesyłane są najczęściej w postaci HTML. Z
protokołem powiązanych jest kilka terminów, które stanowią podstawę zrozumienia
protokołu. I mamy tak:
• connection – wirtualna warstwa transportowa ustanawiana, pomiędzy dwoma
aplikacjami celem komunikacji
• message – podstawowa jednostka komunikacji,
• request – rządanie, zapytanie
• response – odpowiedź
• client – program, który nawiązał połączenie, celem wysłania żądania,
• server – program, który udziela odpowiedzi na żądania
Są to podstawowe pojęcia, które stanowią podstawę rozumienia zasad działanie
protokołu.
Istnieje więcej tych pojęć, jednak te uznałem za najważniejsze.
Podsumowując, nawiązywanie połączenia przebiega następująco:
• Klient przedstawia żądanie pobrania określonego zasobu(polecenie – ścieżka
– protokół; np.: GET /stronka.htm HTTP/1.1
• Jeśli serwer posiada dane, o które zapytano, przesyła informacje
systemowe(protokół, datę, serwer) jak również sam plik o który pytaliśmy.
• Jeśli z kolei serwer nie posiada interesujących nas danych, odpowiada
komunikatem o błędzie(błąd 404 – brak poszukiwanego zasobu)
Chrońmy nasze dane – kryptografia
Algorytmy szyfrowania danych możemy podzielić na dwa rodzaje w zależności od
używanego schematu kluczy danych. Pierwszy rodzaj to
•
Kryptografia kluczy prywatnych
Ten sposób szyfrowania danych (zwany również kryptografią symetryczną, lub
kryptografią z kluczem tajnym) znany jest od dawna. Najprostsze jego rodzaje to
szyfry oparte o przestawianie liter według pewnego, z góry ustalonego schematu.
Ogólny schemat wszystkich tego typu algorytmów jest następujący:
– Strony uzgadniają klucz(e) służące do szyfrowania/deszyfrowania danych.
– W późniejszym czasie strony używają uzgodnionych kluczy do wymiany danych,
ewentualnie zmieniając je co jakiś czas.
Bardziej zaawansowane szyfry symetryczne używane dzisiaj opierają się o operacje
na bitach. Najbardziej znany algorytm to DES używany m.in. do szyfrowania haseł
w systemach UNIX–owych. Używa on skomplikowanych operacji na bitach danych,
których kolejność i rodzaj zależy właśnie od bitów klucza. Inne znane algorytmy
symetryczne to 3DES (mocniejsza wariacja DES, RC2 i RC4. Największą zaletą
algorytmów symetrycznych jest ich szybkość – odpowiednio stosowane, mogą tylko
nieznacznie zmniejszać przepustowość kanału transmisyjnego.
•
Kryptografia kluczy publicznych
Kryptografia kluczy publicznych, zwana także kryptografią asymetryczną zakłada,
że każda transmisja danych używa dwóch kluczy. Jeden z nich, klucz prywatny znany
jest tylko jednej stronie, zaś drugi, klucz publiczny, nie musi być tajny – jest on
powszechnie dostępny i umożliwia przykładowo wysyłanie zaszyfrowanych
informacji do właściciela klucza prywatnego. Ogólny schemat działania metod
szyfrowania z kluczem publicznym jest następujący:
– Każda ze stron generuje parę kluczy (publiczny + prywatny);
– Każda ze stron publikuje swój klucz publiczny w sieci (jest on dostępny dla
wszystkich);
– Jeżeli A chce przesłać wiadomość do B to szyfruje ją kluczem publicznym B. Z
własności algorytmu wynika, że tylko używając klucza prywatnego B można ją
odtworzyć (to jest typowy schemat wymiany danych).
– Jeżeli B chce mieć pewność, że wymienia informacje rzeczywiście z A, to może np.
poprosić A o zaszyfrowanie pewnego tekstu jego kluczem publicznym. Jeżeli B
będzie w stanie odtworzyć tekst używając klucza publicznego A to znaczy, że
rozmawia rzeczywiście z właściwym partnerem.
– Jeżeli B po odebraniu wiadomości od A chce zabezpieczyć się przed sytuacją, w
której A zaprzeczy, że wysłał wiadomość, może poprosić A o zaszyfrowanie jej
dodatkowo swoim kluczem prywatnym (a następnie kluczem publicznym B). B
będzie w stanie ją odszyfrować (najpierw używając swojego klucza prywatnego, a
następnie publicznego klucza A) i A nie będzie mógł zaprzeczyć, że wiadomość
wysłał – wiadomość która dała się odszyfrować kluczem publicznym A musiała
być zaszyfrowana jego kluczem prywatnym.
Jak widać kryptografia asymetryczna likwiduje wszystkie wady kryptografii
symetrycznej. Jest to właściwie rozwiązanie doskonałe, które ma tylko jedną wadę:
szybkość. O ile algorytmy symetryczne (zwłaszcza blokowe) dobrze nadają się do
stosowania „w locie”, to złożoność obliczeniowa szyfrowania czy deszyfrowania z
użyciem kluczy publicznych raczej wyklucza takie zastosowania. Próbą połączenia
najlepszych cech obydwu metod szyfrowania jest.
•
Metoda mieszana
Najważniejszym faktem dla tej metody stała się obserwacja, że niedogodność
algorytmów symetrycznych nie polega na ich „słabości” – dobierając odpowiednio
długi klucz możemy uzyskać zabezpieczenie właściwie dowolnie „silne”.
Problemem jest tylko uzgodnienie tych kluczy. Za to algorytmy symetryczne są o
wiele szybsze.
Wymyślono więc następujący schemat bezpiecznego przesyłania danych:
– A generuje klucz K, który używany będzie później przy przesyłaniu danych
algorytmem symetrycznym;
– A wysyła klucz K do B korzystając z jego klucza publicznego;
– B odczytuje klucz K korzystając ze swojego klucza prywatnego;
– Strony dalej komunikują się korzystając z szyfrowania symetrycznego z użyciem
klucza K
Możliwe są różne wariacje tej metody umożliwiające na przykład:
– Autentyfikację serwera/klienta – można to zrealizować na etapie nawiązywania
połączenia – właściwie sytuacja jest tu taka, jakby używany był tylko algorytm
asymetryczny.
– Okresową wymianę kluczy – strony mogą się umówić, że przykładowo co 15
minut niszczą i od nowa generują klucze symetryczne. Może to być ważne przy
połączeniach trwających bardzo długo i takich, po których przesyła się niewiele
danych. Ktoś posiadający odpowiednio szybki komputer i będący w stanie
podsłuchać szyfrowaną transmisję mógłby wtedy jednak dane odszyfrować.
Opisywana metoda znalazła zastosowanie w:
•
•
SSH (Secure Shell)– protokół bezpiecznego logowania się do systemu
zdalnego. Zaletą SSH w porównaniu z logowaniem się przy pomocy telneta
lub rsh (oczywiście poza bezpieczeństwem) jest fakt, że można wyeliminować
podawanie hasła – do autentyfikacji wystarczający jest klucz prywatny
klienta.
SSL (Secure Socket Layer) – protokół bezpiecznych połączeń WWW.
Technologia HTTP+SSL = HTTPS
Co nas czeka w Internecie każdy się już zapewne przekonał. Poniższe obrazki bardzo
dobrze ilustrują te sytuacje.
Brak poufności
Utrata integralności przesyłanych danych
Podszywanie się pod legalnych użytkowników (Identity spoofing)
Firma Netscape Communications, chcąc zwalczyć sytuacje jak przedstawione
powyżej opracowała „podkładkę” pod istniejące protokoły, działającą poniżej
warstwy aplikacji (HTTP, FTP, SMTP, Telnet, etc.) a powyżej warstw sieci i
transportu (TCP/IP). Jej zadaniem jest stworzenie wirtualnego, odpornego na próby
podsłuchiwania kanału transmisji dla informacji przesyłanych przez aplikacje
(serwery i klienty WWW, FTP, poczty elektronicznej i inne). Najbardziej
rozpowszechnione jest HTTP na SSL (HTTPS).
Jak się okazało jest to doskonałe rozwiązanie, ogólnie stosowne przez instytucje
rządowe, korporacje, sklepy internetowe, internetowe biura maklerskie i przede
wszystkim banki internetowe.
Zapewnia użytkownikowi:
– prywatność – połączenie jest szyfrowane
– autoryzację – klient i serwer określają swoją tożsamość(certyfikaty)
– integralność przesyłanych danych – przez sumy kontrolne.
Skoro już znamy wiemy co nam oferuje to przyjrzyjmy się w jako sposób to działa.
Serwery WWW wykorzystujące protokół SSL mogą prowadzić zarówno szyfrowane
jak i jawne sesje komunikacyjne (transmisja SSL obsługiwana jest na porcie 433, a nie
na standardowym dla protokołu HTTP numerze portu 80).
Zabezpieczone przez SSL strony dokumentu WWW posiadają odmienny format
adresu URL – https://… Warto zauważyć, że nie tylko przeglądarka musi
obsługiwać bezpieczny protokół – przede wszystkim musi go obsługiwać serwer.
A skoro już mowa o przeglądarkach. Należy wspomnieć, które przeglądarki
obsługują ten protokół. Z ogólnie znanych mamy: Netscape Communicator jak
również Internet Explorer. Również Linuxowa przeglądarka Lynx (2.7 i 2.8), choć nie
posiada na razie takich możliwości jak jej okienkowi bracia.
W przeglądarkach Internet Explorer i Netscape Navigator ustanowienie
bezpiecznego połączenia z witryną sygnalizowane jest ikoną z symbolem zamkniętej
kłódki. Każdorazowe przejście z dokumentu chronionego protokołem SSL do
dokumentu niezaszyfrowanego poprzedzane jest wyświetleniem okna z
ostrzegawczym komunikatem, co obrazują rysunki.
Podstawy działania protokołu są następujące: na początku sesji (tzn. w momencie
nawiązania łączności pomiędzy przeglądarką i serwerem) następuje weryfikacja
tożsamości, wymiana kluczy publicznych i ustalenie kluczy sesji. Po zakończeniu
fazy wstępnej dalsza wymiana informacji jest już szyfrowana. Jedna sesja SSL może
przenosić wiele sesji HTTP, podczas gdy w zwykłym HTTP połączenie jest
przerywane po zakończeniu pojedynczego transferu danych.
Dane są szyfrowane kluczem symetrycznym (ten sam klucz do szyfrowania i
odszyfrowania), jednak same klucze w momencie przesyłania, są szyfrowane
algorytmem asymetrycznym, tzn. wykorzystującym klucz prywatny i
odpowiadający mu klucz publiczny, np. algorytmem RSA lub Diffiego– Helmana.
Integralność wiadomości zapewniona jest przez funkcje elektronicznych podpisów,
zwanych też skrótami. Funkcje skrótu umożliwiają przyporządkowanie dowolnemu
tekstowi (dokładnie – dowolnemu ciągowi bajtów) „podpisu”, czyli skrótu (digest),
ściśle związanego z danym tekstem. Ze skrótu nie można odzyskać wiadomości
(zawiera on po prostu mniej informacji). Próba zmiany wiadomości do której dodano
jej skrót powoduje, że skrót przestaje „pasować” do wiadomości. Własności funkcji
skrótu powodują, że znalezienie wiadomości pasującej do skrótu jest bardzo złożone
obliczeniowo. Skrót jest więc trudnym do sfałszowania podpisem wiadomości.
Ze względu na sposób dokonywania autoryzacji SSL jest protokołem
scentralizowanym, inaczej niż np. PGP. Jest on oparty o grupę instytucji
certyfikujących (Certyfing Authorities), w skrócie CA, które opatrują swoim
podpisem certyfikaty poszczególnych serwerów. CA z założenia są godni zaufania, a
uzyskanie podpisu wymaga przedstawienia szeregu dowodów tożsamości. W ten
sposób wchodząc na serwer legitymujący się certyfikatem jednego ze znanych CA
mamy pewność że serwer rzeczywiście jest tym za który się podaje.
Przyjrzyjmy się wiec jakie są rodzaje certyfikatów udostępnia nam protokół SSL.
I tak:
• Certyfikat CA – zbiór informacji reprezentujących tożsamość danej instytucji
certyfikującej. Obecność podpisu danego CA na certyfikacie serwera oznacza,
że CA zaakceptował dowody przedstawione przez firmę występującą o
podpis i swoim certyfikatem poświadcza autentyczność serwera.
•
•
Certyfikat serwera – zbiór informacji reprezentujących tożsamość danego
serwera. Certyfikat serwera musi być opatrzony podpisem CA.
Certyfikat osobisty – znacznie mniej rozpowszechnione są certyfikaty klienta –
firmy promujące używanie tego certyfikatu nazywają go "cyfrowym
paszportem". Wraz z podpisem odpowiedniego CA pozwala potwierdzić
tożsamość klienta.
Firma Netscape proponuje jeszcze jeden: certyfikat atrybutu. Stanowi on
rozszerzenie istniejących certyfikatów, jednak sam nie stanowi dowodu tożsamości.
Należało by jednak wspomnieć czym owe certyfikaty są naprawdę.
Są to zbiory danych jednoznacznie identyfikujące pewną jednostkę, oraz pozwalające
stwierdzić czy osoba, która się nim legitymuje jest rzeczywiście tym, za kogo się
podaje. Certyfikat taki zawiera:
• Nazwę certyfikowanego obiektu
• Identyfikator obiektu
• Klucz publiczny obiektu
• Czas ważności
• Nazwę wystawcy certyfikatu
• Identyfikator wystawcy
• Podpis wystawcy
Problemem który pojawia się wraz z certyfikatami jest ich unieważnianie. O ile łatwo
jest stwierdzić, czy certyfikat nie wygasł – zawiera on bowiem odpowiednie pole, to
może się okazać, że należy certyfikat unieważnić przed jego terminem wygaśnięcia.
Jeśli np. z pracy odchodzi pracownik posiadający dostęp do ważnych danych firmy,
to powinna istnieć możliwość odebrania mu tych uprawnień niezależnie od terminu
ważności jego certyfikatu.
Rozwiązaniem tego problemu są listy unieważnień (certificate revocation lists)
przechowywane na wszystkich serwerach wystawiających certyfikaty. Ich działanie
polega na tym, że klient przy sprawdzaniu autentyczności dowolnego certyfikatu
musi zgłosić się do jego wystawcy i poprosić o sprawdzenie, czy przypadkiem nie
został on unieważniony przed czasem.
Jednak taki dodatkowy ruch w Internecie nie jest najlepszym rozwiązaniem, gdyż
wpływa to negatywnie na funkcjonalność.
Przyjrzyjmy się teraz dokładniej algorytmowi nawiązywania połączenia. Dla
uproszczenia oznaczmy sobie przez U – użytkownika, a przez S – serwer. W nawiasach
znajdą się komunikaty wysyłane pomiędzy stronami.
U => S (ClientHello)
Użytkownik wysyła do serwera zgłoszenie zawierające m.in.
obsługiwaną wersję protokołu SSL, dozwolone sposoby szyfrowania i
kompresji danych oraz identyfikator sesji. Komunikat ten zawiera
również liczbę losową używaną potem przy generowaniu kluczy.
U <= S (SerwerHello)
Serwer odpowiada podobnym komunikatem w którym zwraca
użytkownikowi wybrane parametry połączenia: wersję protokołu SSL,
rodzaj szyfrowania i kompresji, oraz podobną liczbę losową.
U <= S (Certificate)
Serwer wysyła swój certyfikat pozwalając użytkownikowi na
sprawdzenie swojej tożsamości. Etap ten nie jest regułą, ale zazwyczaj
występuje
U<=S (ServerKeyExchange)
Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i
długość tego klucza jest określona przez typ algorytmu przesłany w
poprzednim komunikacie.
U <= S (ServerHelloDone)
Serwer zawiadamia, że użytkownik może przejść do następnej fazy
zestawiania połączenia.
U => S (ClientKeyExchange)
Użytkownik na podstawie ustalonych w poprzednich komunikatach
dwóch liczb losowych (swojej i serwera) generuje klucz sesji używany
do faktycznej wymiany danych. Następnie wysyła go serwerowi
używając jego klucza publicznego. Wygenerowany klucz jest kluczem
algorytmu symetrycznego (najczęściej DES). Jest on jednak ustalony w
sposób bezpieczny i znany jest tylko komunikującym się stronom.
U => S (ChangeCipherSpec)
Użytkownik zawiadamia,
komunikację szyfrowaną.
że
serwer
może
przełączyć
się
na
U => S (Finished)
...oraz, że jest gotowy do odbierania danych zakodowanych.
U <= S (ChangeCipherSpec)
Serwer zawiadamia, że wykonał polecenie – od tej pory wysyłał będzie
tylko zaszyfrowane informacje.
U <= S (Finished)
...i od razu wypróbowuje mechanizm – ten komunikat jest już wysyłany
bezpiecznym kanałem.
Protokół SSL przewiduje również kontrolowane zakończenie połączenia. Jest to
dosyć ważne, gdyż nie można dopuścić do sytuacji, w której potencjalny intruz jest
w stanie przerwać fizyczny kanał komunikacyjny i tym samym zniekształcić treść
przesyłanej wiadomości. Do kontrolowania zakończenia połączenia służy komunikat
ClosureAlert.
Powyższy przykład zawierał tylko sprawdzenie autentyczności serwera. A przecież
należał oby sprawdzić też użytkownika. W tym celu korzysta się z trzech
dodatkowych komunikatów:
U <= S (CertificateRequest)
Po przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby
otrzymać certyfikat użytkownika
U => S (Certificate)
Po otrzymaniu komunikatu ServerHelloDone użytkownik odsyła swój
certyfikat
U => S (CertificateVerify)
Użytkownik musi potwierdzić, że faktycznie posiada klucz prywatny
odpowiadający wysłanemu certyfikatowi. W tym celu użytkownik
szyfruje swoim kluczem prywatnym skrót wszystkich dotychczas
ustalonych danych o połączeniu i wysyła go korzystając z tego
komunikatu.
Nawiązanie połączenia SSL jest procesem dość długotrwałym i wymagającym
skomplikowanych obliczeń. W przypadku wielu krótkich połączeń pożądana byłaby
możliwość kontynuowania połączenia bez ponownej wymiany kluczy publicznych,
ustalania klucza sesji itp. (Podobna sytuacja ma miejsce w przypadku protokołu
HTTP – stosowane są tam tzw. połączenia trwałe – persistent connections.
Protokół SSL przewiduje taką możliwość. Jeżeli w komunikacie ClientHello
użytkownik poda SessionId równy identyfikatorowi jednej z poprzednich sesji, to
serwer przyjmie, że użytkownik chce kontynuować połączenie z użyciem
poprzednio używanego klucza.
Specyfikacja protokołu SSL
W chwili obecnej istnieją dwie specyfikacje SSL:
– SSL 2.0 z listopada 1994 roku
– SSL 3.0 z listopada 1996 roku
Wersja 3.0 ma poprawione wiele wad wersji 2.0 oraz umożliwia kompresję danych.
Wersja SSL 3.0 jest wstecznie zgodna z 2.0.
Specyfikacja SSL obejmuje dwa podstawowe protokoły:
– SSL Handshake Protocol
– SSL Record Protocol.
Protokół SSL Handshake określa metody prowadzenia połączenia serwer–
użytkownik. (przeglądarka WWW), mające na celu ustalenie parametrów
bezpiecznej sesji komunikacyjnej np. algorytmy szyfrowania danych, algorytmy
sprawdzania autentyczności i integralności informacji, klucze szyfrowania.
Protokół SSL Record określa format przesyłanych pakietów danych w ramach
chronionej sesji komunikacyjnej. Wersja 3 specyfikacji SSL przewiduje stosowanie
algorytmów szyfrowania DES, Triple–DES, IDEA, RC2 i RC4 wraz z
jednokierunkową funkcją skrótu MD5 lub SHA oraz algorytmy RSA i DSS do
tworzenia podpisów cyfrowych. W procesie negocjacji kluczy szyfrowania, SSL
używa algorytmu Diffiego–Hellmana.
Specyfikacja protokołu negocjacyjnego SSL
Protokół negocjacyjny SSL ma 2 główne fazy. Pierwsza jest używana do
ustanowienia poufnego połączenia. Druga faza używana jest do uwierzytelnienia
klienta.
Faza 1
Pierwsza faza jest fazą inicjacji połączenia gdzie obie strony wymieniają wiadomości
„hello”. Klient inicjuje konwersację przez wysłanie wiadomości CLIENT–HELLO.
Serwer odbiera wiadomość CLIENT–HELLO i przetwarzając ją odpowiada
wiadomością SERWER–HELLO. W tym momencie klient i serwer mają
wystarczające informacje, aby dowiedzieć się czy nowy klucz główny jest potrzebny
czy nie. Kiedy nowy klucz główny nie jest wymagany, klient i serwer natychmiast
przechodzą do fazy 2.
Kiedy nowy klucz główny jest potrzebny, wiadomość SERWER–HELLO zawiera
wystarczające informacje dla klienta aby go wygenerował. Klient generuje nowy
klucz główny i odpowiada wiadomością CLIENT–WRITE–KEY.
Każdy węzeł końcowy (serwer lub klient) SSL używa pary szyfrów na połączenie (w
sumie 4 szyfry). Jeden szyfr używa do transmisji wychodzącej i jeden do transmisji
przychodzącej. Klient lub serwer generują klucz sesji, faktycznie generują 2 klucze,
SERWER–READ–KEY (również znany jako CLIENT–WRITE–KEY) i SERWER–
WRITE–KEY (również znany jako CLIENT–READ–KEY). Klucz główny jest
używany przez klienta i serwer do generowania zmiennych kluczy sesji.
Na koniec, serwer wysyła wiadomość SERWER–VERIFY do klienta po określeniu
klucza głównego. Ten końcowy krok uwierzytelnia serwer, ponieważ tylko serwer
który ma właściwy klucz publiczny może poznać klucz główny.
Faza 2
Druga faza jest fazą uwierzytelniania. Serwer był już uwierzytelniony przez klienta
w fazie 1, tak więc ta faza jest podstawową używaną do uwierzytelnienia klienta. W
typowym scenariuszu serwer wymaga coś od klienta i wysyła żądanie. Klient
odpowiada pozytywnie jeżeli ma wymagane informacje lub wysyła wiadomość
ERROR, jeżeli nie ma.
Kiedy jedna strona jest uwierzytelniona przez drugą stronę, to wysyła wiadomość
FINISHED. Dla klienta, wiadomość CLIENT–FINISHED zawiera zaszyfrowane
CONNECTION–ID do weryfikacji przez serwer. Jeżeli weryfikacja jest błędna, to
serwer wysyła wiadomość ERROR.
Jedna strona wysyłając wiadomość FINISHED, musi kontynuować nasłuchiwanie
wiadomości, aż do otrzymania również wiadomości FINISHED.
Błędy
Obsługa błędów w protokóle połączenia SSL jest bardzo prosta. Kiedy błąd jest
wykryty, strona wykrywająca wysyła wiadomość do drugiej strony. Błędy które nie
są naprawialne (do odtworzenia) powodują przerwanie bezpiecznego połączenia
klienta i serwer.
Protokół negocjacyjny SSL definiuje następujące błędy:
NO–CIPHER–ERROR – ten błąd zwracany jest przez klienta do serwera, kiedy
klient nie może znaleźć szyfru lub rozmiaru klucza, który to jest obsługiwany przez
serwer. Ten błąd nie jest naprawialny.
NO–CERTIFICATE–ERROR – Kiedy wiadomość REQUEST–CERTIFICATE jest
wysłana, ten błąd może być zwrócony, jeżeli klient nie ma certyfikatu. Ten błąd jest
do odtworzenia.
BAD–CERTIFICATE–ERROR – ten błąd jest zwracany kiedy certyfikat jest
uważany za zły przez stronę odbierająca. Ten błąd jest do odtworzenia.
UNSUPPORTED–CERTIFICATE–TYPE–EROR – ten błąd jest zwracany kiedy
klient/serwer odbiera rodzaj certyfikatu, który nie jest obsługiwany. Ten błąd jest do
odtworzenia .
ERROR – wiadomość ta jest wysyłana kiedy jest wykryty błąd. Po wysłaniu
wiadomości, strona wysyłająca zamyka połączenie, natomiast odbierająca zapisuje
błąd i zamyka połączenie.
Wiadomość niezaszyfrowana jest wysyłana, jeżeli błąd pojawia się podczas
negocjacji klucza sesji. Po uzgodnieniu klucza sesji, błędy wysyłane są szyfrowane
jak wszystkie inne wiadomości.
Literatura
•
•
•
•
•
Specyfikacja HTTP/1.1; RFC 2616
Specyfikacja SSL
Stephen Thomas – "SSL and TLS Essentials", Wiley and Sons 2000
Opis protokołu SSL 2. 0 (Netscape)
Propozycja standardu SSL 3.0 (Netscape).