Crypto-IT

Protokoły warstwy aplikacji dostarczają aplikacjom interfejsy, które umożliwiają im wykorzystywanie sieci komputerowych. Warstwa aplikacji jest opisana w podobny sposób przez oba modele sieciowe, TCP/IP oraz OSI. Obie specyfikacje różnią się jedynie w detalach.

• HTTP
• HTTPS
• SSL/TLS
• IRC

HTTP jest najbardziej rozpowszechnionym protokołem warstwy aplikacji, używanym w Internecie. Pozwala zarówno na pobieranie danych z serwerów (stron internetowych) jak i na przesyłanie pewnych danych do serwerów.

HTTP jest tak stary jak Internet. Pierwsza wersja tego protokołu (HTTP/0.9) umożliwiała jedynie pobieranie stron HTML (HyperText Markup Language). Dwie nowsze wersje, HTTP/1.0 i HTTP/1.1, zostały opublikowane odpowiednio w roku 1996 i 1997. Najnowsza dokumentacja HTTP/1.1 składa się z 6 specyfikacji: RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 oraz RFC 7235. Najpopularniejszą wersją protokołu jest HTTP/1.1. Niektóre starsze lub prostsze przeglądarki internetowe wykorzystują starszą wersję, HTTP/1.0. Najwcześniejsza wersja protokołu, HTTP/0.9, jest używana stosunkowo rzadko (jednakże, jest wciąż wspierana przez wiele aplikacji).

Kolejna wersja protokołu (HTTP/2) została oficjalnie opublikowana jako RFC 7540 w maju 2015 roku.

HTTP jest protokołem typu żądanie-odpowiedź (ang. request-response) pomiędzy klientem a serwerem. Każda sesja HTTP jest inicjowana przez utworzenie połączenia TCP do serwera (zwykle do portu 80), a następnie wysłanie żądania ze wskazanym adresem URL do pobrania. Serwer odpowiada przesyłając żądany plik (lub inne dane) i, zwykle, kończy połączenie.

W HTTP/1.1 jedno pojedyncze połączenie jest używane do pobrania pliku ze stroną WWW oraz wszystkich innych plików potrzebnych do wyświetlenia jej zawartości (obrazów, stylów css, skryptów). Nie ma potrzeby, tak jak w poprzednich wersjach HTTP, ustanawiania osobnych połączeń oddzielnie dla każdego pliku. Trzeba tu jednak zaznaczyć, że po przesłaniu wszystkich żądanych danych, serwer kończy połączenie z klientem i żadne informacje o współpracy dwóch komputerów nie są dłużej przechowywane (przynajmniej z punktu widzenia protokołu HTTP). Protokół HTTP nie utrzymuje więc trwałego połączenia pomiędzy komunikującymi się stronami.

Dodatkowo, HTTP nie gromadzi informacjach o aktualnym stanie komunikacji pomiędzy komputerami. Każda wiadomość w protokole HTTP traktowana jest oddzielnie i sposób jej przetwarzania nie zależy od wcześniejszej komunikacji pomiędzy klientem a serwerem. HTTP może służyć do transmitowania danych różnego typu, tak długo jak komunikujące się strony są w stanie właściwie je zinterpretować. Typ danych musi zostać określony przy użyciu właściwego typu MIME.

Najpopularniejszymi portami przypisanymi do HTTP są port 80 oraz (rzadziej) port 8080. Serwer HTTP nasłuchuje przychodzących połączeń na jednym z tych portów. Jeśli odbierze wiadomość od klienta, przesyła mu potwierdzenie jej otrzymania, a następnie właściwą odpowiedź. Odpowiedź zwykle zawiera żądany przez klienta plik, ale serwer może zwrócić też błąd lub inną informację kontrolną.

W HTTP/0.9 żądania wysyłane do serwera były dość proste. Składały się jedynie ze słowa kluczowego GET, z następującym po nim adresem URL i znakiem nowej linii newline. Proste zapytanie HTTP/0.9 może wyglądać podobnie do przykładowego pokazanego poniżej:

W odpowiedzi serwer powinien przesłać żądany dokument (tekst ASCII dokumentem HTML albo czysty tekst poprzedzony słowem kluczowym PLAINTEXT). Serwer nie będzie przetrzymywał żadnych informacji związanych z aktualnym stanem przeglądarki użytkownika.

Obie nowe wersje protokołu, HTTP/1.0 i HTTP/1.1, pozwalają użytkownikowi przesłać dodatkowe informacje w zapytaniu. Po pierwsze, dostępnych jest więcej metod:

• GET - spełnia takie same zadania jak we wcześniejszej wersji HTTP/0.9, czyli jest używany do pobierania z serwera danych wskazanych przez załączony adres URL,
• HEAD - jest podobny do GET, ale odpowiedź z serwera zawierać będzie jedynie Linię Statusu (ang. Status-Line), czyli wersję protokołu, kod statusu (ang. Status-Code) i powód przesyłania odpowiedzi (ang. Reason-Phrase) oraz inne informacje dotyczące serwera w nagłówku odpowiedzi (ang. Response-Header),
• POST - jest wykorzystywany do wysyłania informacji na serwer lub załączania plików przy użyciu formularzy HTML,
• PUT - zasób wskazywany przez załączoną ścieżkę jest zastępowany przez załączone dane,
• DELETE - usuwa zasoby wskazywane przez załączoną ścieżkę,
• CONNECT - ustanawia połączenie tunelowe do serwera identyfikowanego za pomocą załączonej ścieżki. Ta metoda jest wykorzystywana głównie przez protokoły SSL/TLS. Pozwala na skonfigurowanie serwera proxy, który będzie wykorzystywany do przesyłania wiadomości od klienta pod adres URL przesyłany jako parametr,
• TRACE - jest metodą używaną do testowania i debugowania. Dostarcza użytkownikowi logi odnośnie trasy, którą pokonują jego żądania,
• OPTIONS (HTTP/1.1 i nowsze) - przesyła żądanie dostarczenia jedynie informacji dotyczących konfiguracji serwera, bez przesyłania żadnych zasobów.

Część metod zaprezentowanych powyżej jest uważana za bezpieczne i może być wykorzystywana jedynie do pobierania informacji z serwera (HEAD, OPTIONS, GET, TRACE). Z kolei, niektóre metody mogą powodować efekty uboczne na serwerze, lub nawet na zewnętrznych stronach (DELETE, PUT, POST). W praktyce sposób przetwarzania wiadomości GET nie jest ograniczony w żaden sposób, więc ta metoda również powinna być traktowana jako niebezpieczna.

Pierwsza linijka żądania zawiera nazwę użytej metody, z dołączonymi do niej adresem URL oraz informacjami odnośnie wersji protokołu. Może być podobna do przedstawionej poniżej:

Poniżej pierwszej linijki może znajdować się kilka kolejnych linii nazywanych nagłówkami. Każdy nagłówek zawiera parę nazwa-wartość (nazwa oddzielona jest od wartości dwukropkiem). Istnieje szereg popularnych nagłówków, załączanych do większości żądań klienta:

• Host - zawiera adres URL hosta,
• User-Agent - przechowuje informacje o przeglądarce użytkownika,
• Content-Type lub Content-Length - dostarcza informacji odnośnie ewentualnych dodatkowych danych załączonych przez użytkownika na końcu wiadomości,
• Accept - informacje o dostępnych typach MIME (na przykład audio/mpeg lub image/jpeg),
• Accept-Language - informacje o dostępnych językach,
• Accept-Encoding - informacje o dostępnych kodowaniach,
• Referer (pisane z błędem) - dostarcza informacji odnośnie strony źródłowej.

Nagłówki są zakończone pustą linijką, za którą mogą znajdować się dodatkowe dane przesyłane przez klienta (na przykład informacje z formularzy). Pozostała część żądania może wyglądać następująco:

W odpowiedzi serwer wysyła własną wiadomość HTTP. Podobnie jak w przypadku żądań klienta, zaczyna się ona od Linii Statusu (ang. Status-Line), który zawiera takie same informacje (czyli wersję protokołu, numer Status-Code oraz pole tekstowe Reason-Phrase).

Za pierwszą linią może znajdować się szereg nagłówków odpowiedzi, na przykład:

• Server - nazwa serwera,
• Via - lista serwerów proxy użytych do przesłania odpowiedzi,
• Connection - opcje kontrolne dla aktualnego połączenia (keep-alive jeśli serwer oczekuje na więcej zapytań albo close jeśli połączenie będzie zakończone po obsłużeniu ostatniego otrzymanego zapytania),
• Content-Encoding - rodzaj kompresji użytej do spakowania danych,
• Content-Type, Content-Length, Content-Language - dla przekazania dodatkowych informacji dotyczących przesyłanych danych.

Nagłówki odpowiedzi są zakończone pustą linią, za która mogą się znajdować dodatkowe dane przesyłane przez serwer. Odpowiedź mogłaby wyglądać na przykład tak:

Dane przesyłana przez serwer mogą zawierać kod html żądanej strony WWW. Poniżej znajduje się przykład wiadomości od serwera do klienta, która zawiera kompletną stronę internetową hello_world.html:

Największą słabością HTTP jest fakt, że cała komunikacja pomiędzy klientem i serwerem jest nieszyfrowana. Wszystkie wiadomości mogą być z łatwością podsłuchane w czasie kiedy przesyłane są z jednego komputera na drugi. HTTPS jest najpopularniejszym sposobem nawiązywania bezpiecznych połączeń HTTP.

Inną cechą protokołu, którą można wykorzystać jest możliwość użycia żądań z metodą TRACE do zbierania informacji związanych z architekturą atakowanego systemu. Można temu przeciwdziałać wyłączając obsługę metody HTTP TRACE za pomocą mod_rewrite.

Problemy związane z wieloma różnymi implementacjami

Zidentyfikowanych jest szereg problemów związanych z bezpieczeństwem HTTP, powodowanych przez fakt, że różne aplikacje działające zarówno po stronie klienta, jak i po stronie serwera, zapewniają różny stopień wsparcia dla starszych wersji protokołu.

Specyfikacja HTTP/1.0 wymaga, aby klient był w stanie odbierać wiadomości przesłane zarówno przy użyciu protokołu HTTP/1.0, jak i HTTP/0.9. Mimo, iż w kilku innych dokumentach można znaleźć inne rekomendacje, wiele przeglądarek internetowych wspiera HTTP/0.9 i jest przez to podatnych na ataki przy użyciu metody opisanej poniżej:

1. Napastnik przygotowuje wiadomość zawierającą żądanie GET, która ma być wysłana na jeden z nieprzygotowanych na to portów na serwerze. Żądany adres URL jest błędny i zawiera tag <html>. Pierwsza linia wiadomości może być podobna do takiej: GET /<html><body>something HTTP/1.0, kolejna linijka zawierałaby adres i numer portu serwera. Ustawienia dolnych warstw w wiadomości fałszywie wskazują, że pakiet został wysłany z atakowanego komputera ofiary.
2. Ponieważ serwer nie spodziewa się wiadomości HTTP na wybranym porcie, zwrócona zostanie informacja o błędzie. Informacja o błędzie nie będzie związana z protokołem HTTP w żaden sposób, więc nie będzie zrozumiała dla przeglądarki internetowej na atakowanym komputerze klienta. Jednakże, wiadomość ta może zawierać oryginalne żądanie, zacytowane w jej treści, z wyjaśnieniem, że jej format był niepoprawny. W rezultacie, przeglądarka zinterpretuje tę wiadomość w jedyny możliwy sposób - jako odpowiedź HTTP/0.9 zawierającą jedynie dokument HTML. Przeglądarka wyświetli stronę internetową, której zawartość zależy jedynie od tego, jakie dane zostały umieszczone przez napastnika po tagu <html> w fałszywym żądaniu wysłanym do serwera. Cała wiadomość TCP/IP otrzymana przez klienta (czyli przez atakowany system) będzie wyglądać jak prawdziwa wiadomość otrzymana z serwera (rzeczywiście, wiadomość będzie wysłana przez serwer).

Inne rodzaje problemów są związane z faktem, że HTTP/1.1 pozwala na kodowanie znaku nowej linii za pomocą pojedynczego znaku CR. Obecnie, większość serwerów internetowych (na przykład Apache oraz IIS) nie przestrzegają tego wymagania i nie traktują pojedynczego znaku CR jako wyznacznika nowej linii. Natomiast większość obecnych przeglądarek internetowych (Internet Explorer, Safari, Opera) uznaje ten znak za nową linię. W rezultacie wiadomości, które zawierają znaki CR, mogą być różnie interpretowane przez poszczególne przeglądarki i serwery.

Podobny problem związany jest z ideą wielolinijkowych nagłówków wprowadzonych w HTTP/1.1. W teorii, linia nagłówku, która zaczyna się od spacji, powinna być traktowana jako kontynuacja poprzedniego nagłówku. Jednak, podobnie jak poprzednio, większość serwerów (w tym Apache oraz IIS) akceptuje wielolinijkowe nagłówki, w przeciwieństwie do większości przeglądarek (wliczając w to Internet Explorer, Safari i Operę). Wobec tego wiadomości zawierające wielolinijkowe nagłówki mogą być przetwarzane w zupełnie różny sposób.

Specyfikacja HTTP nie określa jak serwery i aplikacje klienckie powinny traktować powtarzające się lub dwuznaczne nagłówki. Jak można było się spodziewać, różne aplikacje przetwarzają je w różny sposób (akceptują pierwszy, akceptują ostatni, odrzucają wszystkie).

Kłopoty z bezpiecznym używaniem protokołu HTTP wiążą się z tymi samymi czynnikami, które sprawiają, że cały Internet jest podatny na różnego rodzaje nadużycia i ataki - bardzo wielu sprzedawców i producentów, niekompatybilne i tworzone bez wcześniejszego dokładnego zaprojektowania funkcjonalności oraz brak dbałości o zabezpieczenia we wczesnej fazie powstawania Internetu.

HTTPS umożliwia przeglądanie stron internetowych przy użyciu protokołu HTTP z dodatkowym szyfrowaniem. Pierwsza wersja HTTPS została wydana w roku 1994 przez Netscape Communications.

Wszystkie wiadomości HTTP są szyfrowane za pomocą algorytmów SSL lub TLS, które działają również w Warstwie Aplikacji, ale poniżej protokołu HTTP. Ewentualny napastnik, który podsłucha komunikację, będzie w stanie zobaczyć jedynie wiadomości SSL lub TLS, zawierające zaszyfrowane dane. Wykorzystywany algorytm SSL/TLS używa zwykle długoterminowych kluczy publicznego i prywatnego do generowania sekretnych kluczy symetrycznych zabezpieczających poszczególne sesje komunikacyjne.

Jak już to zostało powiedziane wcześniej, algorytm HTTPS składa się z dwóch algorytmów, HTTP i SSL/TLS. HTTPS operuje na protokole Warstwy Transportowej, którym zwykle jest TCP. Połączenie TCP nie jest szyfrowane, co oznacza, że adresy IP i numery portów mogą być widoczne dla postronnych obserwatorów. Ewentualny napastnik może poznać nazwę domeny, ale nie będzie w stanie ustalić dokładnego adresu URL.

Siła szyfrowania zależy od implementacji protokołu SSL/TLS użytego do zabezpieczenia danych HTTP.

Zalecane jest używanie algorytmów, które zapewniają poufność doskonałą (ang. perfect forward secrecy). Gwarantują one, że nawet jeśli napastnik wejdzie w posiadanie jednego z długoterminowych kluczy asymetrycznych (użytych do utworzenia sesji HTTPS), nie będzie w stanie uzyskać dzięki temu krótkoterminowego klucza sesji i odszyfrować właściwych wiadomości. Nie wszystkie algorytmy szyfrowania asymetrycznego zapewniają bezpieczeństwo takiej jakości. Dwoma znanymi algorytmami, które spełniają ten warunek są: protokół negocjowania sekretnego klucza Diffiego-Hellmana oraz Krzywa eliptyczna Diffiego-Hellmana.

Poza szyfrowaniem, HTTPS umożliwia również uwierzytelnianie stron internetowych. Zabezpiecza to przed atakami typu man-in-the-middle. Serwery mogą się uwierzytelnić poprzez dostarczenie odpowiednich certyfikatów do przeglądarek internetowych. Wszystkie przeglądarki mają zainstalowany zestaw certyfikatów od najważniejszych dostawców (takich jak Symantec, Comodo, GoDaddy, itd.) i są w stanie zweryfikować autentyczność drugiej strony.

Jeśli przeglądarka internetowa nie zdoła potwierdzić autentyczności strony www, z którą usiłuje się połączyć (na przykład z powodu nieprawidłowego certyfikatu), to informuje o tym użytkownika za pomocą odpowiedniego komunikatu. Ponadto zaszyfrowane połączenia są zwykle prezentowane użytkownikowi przy pomocy ikony zielonej kłódki umieszczonej gdzieś w pobliżu paska adresu URL.

URL w protokole HTTPS jest taki sam jak w protokole HTTP, za wyjątkiem tokena (ang. scheme token, https:// vs. http://). Jak to już było wspomniane wcześniej, większość przeglądarek sygnalizuje używanie protokołu HTTPS za pomocą ikony przedstawiającej zieloną kłódkę.

HTTPS wykorzystuje zwykle inny numer portu niż protokół HTTP: domyślnie 443, w przeciwieństwie do portu 80 używanego przez HTTP.

Aby komunikacja HTTPS była całkowicie bezpieczna, cała zawartość strony internetowej musi być przesyłana za pomocą szyfrowanego połączenia HTTPS (oznacza to, że nie tylko tekst, ale i obrazy, media, itd.). W celu uniemożliwienia podsłuchiwania i wielu innych typów ataków, cała komunikacja bez żadnych wyjątków musi odbywać się za pomocą protokołu HTTP.

Zarówno TLS jak i SSL odnoszą się to tego samego zestawu protokołów Warstwy Aplikacji. Służą one do ochraniania danych wymienianych przez inne protokoły Warstwy Aplikacji.

SSL zostało oryginalnie opracowane w amerykańskiej firmie Netscape. Istnieją trzy wersje protokołu SSL, opracowane odpowiednio w latach 1994, 1995 oraz 1996. Pierwsza wersja TLS została zaprezentowana w 1999 roku, jako ulepszenie istniejącej trzeciej wersji protokołu SSL. Dwie kolejne wersje TLS zostały oficjalnie wydane po roku 1999: TLS 1.1 w 2006 oraz TLS 1.2 w 2009. Trzecia wersja, TLS 1.3, jest aktualnie (rok 2016) przygotowywana i ma niebawem być oficjalnie wydana. Ogólnie rzecz ujmując, we wszystkich kolejnych nowszych wersjach TLS i SSL wprowadzano coraz lepsze protokoły kryptograficzne oraz usuwano starsze i mniej niezawodne wersje. Zmiana nazwy protokołu, z SSL na TLS, wynikała z chęci uniknięcia potencjalnych problemów prawnych ze strony Netscape.

Obecnie, klucze publiczne i prywatne wykorzystywane przez algorytmy szyfrowania asymetrycznego TLS/SSL składają się z tysięcy bitów. Istnieje wiele bibliotek implementujących protokół TLS/SSL, dostępnych dla najpopularniejszych języków programowania i systemów operacyjnych. OpenSSL jest prawdopodobnie najpopularniejszym takim projektem.

Protokoły TLS/SSL operują na Warstwie Aplikacji, pod innymi protokołami Warstwy Aplikacji i mają za zadanie zabezpieczanie wiadomości wymienianych przez te ostatnie. Obecnie, protokoły TLS/SSL są wykorzystywane do zabezpieczania wszystkich głównych funkcjonalności w Internecie:

• Przeglądania stron WWW (HTTPS)
• Poczty email
• Voice-over-IP (VoIP)
• Komunikatorów internetowych

TLS/SSL zwykle współpracuje z niezawodnym (ang. reliable) protokołem TCP działającym na Warstwie Transportowej. Należy jednak zauważyć, że istnieją również wersje, współpracujące z innymi protokołami Warstwy Transportowej, między innymi z bardziej zawodnymi protokołami, jak UDP.

TLS/SSL dostarcza trzech głównych funkcjonalności:

• Szyfrowanie
• Autoryzacja
• Spójność wiadomości

Każde z tych zastosowań zostało opisane poniżej.

Protokół TLS/SSL można podzielić na dwa pod-protokoły, używane w różnych fazach komunikacji:

• Handshake Protocol, który służy do wynegocjowania wszystkich parametrów połączenia i ustanowienia bezpiecznej sesji.
• Record Protocol, który zabezpiecza wszystkie wymieniane później przez powiązany protokół Warstwy Aplikacji wiadomości (czyli wiadomości, które zawierają informacje, które powinny być chronione, jak na przykład zawartość stron www lub wiadomości emailowe).

Wiadomości TLS są nazywane rekordami (ang. records). Każdy rekord zawiera szereg pól, które opisują wersje protokołu, typ wiadomości, jej długość, itd. Za polami kontrolnymi znajdują się właściwe dane, a następnie (opcjonalnie) kod uwierzytelnienia wiadomości MAC oraz (również opcjonalnie) bajty dopełnienia.

Przed nawiązaniem połączenia, obie strony negocjują parametry szyfrowania podczas nawiązywania połączenia, czyli tak zwanego protokołu TLS handshake. Uczestnicy muszą zgodzić się, jakiego algorytmu szyfrującego będą używali i utworzyć właściwe klucze szyfrujące. Używane potem do zabezpieczenia wiadomości szyfrowanie jest symetryczne, a wynegocjowane sekretne klucze symetryczne są zazwyczaj wykorzystywane tylko podczas tej jednej sesji.

Proces ustalania współdzielonego sekretnego klucza jest bezpieczny i potencjalny napastnik nie byłby w stanie uzyskać go, nawet jeśli przechwyciłby wszystkie wiadomości wymienione pomiędzy klientem a serwerem. Ponadto, protokół handshake gwarantuje, że wynegocjowany sekretny klucz nie został zmodyfikowany przez napastnika podczas transmisji (co oznacza, że komunikacja jest niezawodna (ang. reliable).

Cały proces nawiązywania bezpiecznego połączenia jest odporny na ataki man-in-the-middle.

Nawiązujące połączenie strony mogą się uwierzytelnić przed utworzeniem sesji. Autoryzacja przeprowadzana jest z wykorzystaniem cyfrowych certyfikatów, podpisanych przez zaufane strony trzecie (ang. trusted third parties) oraz algorytmów szyfrowania asymetrycznego z kluczami publicznymi i prywatnymi.

Należy zauważyć, że proces uwierzytelniania nie jest obowiązkowy i może zostać pominięty przez jedną, lub więcej, stron. Zwykle, dla większej wygody, jedynie serwer uwierzytelnia siebie przed nawiązaniem połączenia z klientem.

Klient może potwierdzić tożsamość drugiej strony, za pomocą otrzymanego klucza publicznego. Klucz taki jest zwykle częścią certyfikatu, otrzymanego od zaufanych Dostawców Certyfikatów (ang. Certificate Authorities). Klient używa klucz publiczny do odszyfrowania porcji danych, otrzymanych wcześniej w formie zaszyfrowanej za pomocą klucza prywatnego serwera. Jeśli informacja może być poprawnie odszyfrowana za pomocą klucza publicznego będącego częścią cyfrowego certyfikatu, to klient może przyjąć, że druga strona naprawdę jest tym, za kogo się podaje (ponieważ posiada właściwy klucz prywatny).

Komunikacja ochrania za pomocą protokołu TLS/SSL jest niezawodna (ang. reliable). TLS/SSL gwarantuje spójność wszystkich wymienionych pomiędzy stronami wiadomości.

Sprawdzanie spójności wiadomości bazuje na wykorzystaniu kodów uwierzytelniania wiadomości, dołączanych do przesyłanych danych. Zabezpiecza to wymieniane dane przed uszkodzeniami podczas transmisji oraz celowym modyfikacjom ich treści.

Podobnie do innych funkcjonalności TLS/SSL, spójność wiadomości może być zapewniona przez różne algorytmy kryptograficzne, w zależności od możliwości klienta i serwera.

Protokół handshake rozpoczyna się zaraz po tym, kiedy obie strony zgodzą się na używanie TLS. Klient i serwer wspólnie ustalają parametry bezpiecznego połączenia, które zamierzają utworzyć.

1. Na początku klient przesyła listę wspieranych algorytmów szyfrów i funkcji haszujących.
2. Serwer wybiera preferowane algorytmy z otrzymanej listy i informuje klienta o swojej decyzji.
3. Zwykle (jest to krok opcjonalny) serwer uwierzytelnia siebie za pomocą właściwego cyfrowego certyfikatu, który zawiera szereg informacji opisujących serwer, takich jak jego nazwa i klucz publiczny. Klucz publiczny jest wykorzystywany przez klienta do sprawdzenia prawdziwości serwera.
4. Klient może wykorzystać klucz publiczny serwera do zaszyfrowania losowego numeru, który następnie jest odsyłany do serwera. Tylko serwer będzie w stanie odszyfrować tę liczbę (za pomocą swojego klucza prywatnego), która może pełnić role sekretnego klucza symetrycznego, podczas dalszej komunikacji pomiędzy tymi dwoma stronami.
5. Inną, lepszą metodą uzyskania współdzielonego klucza symetrycznego jest użycie bezpiecznego algorytmu asymetrycznego negocjowania sekretnego klucza. Szczególnie polecane są dwa algorytmy asymetryczne, które zapewniają poufność doskonałą (ang. perfect forward secrecy): Diffiego-Hellmana oraz Krzywa eliptyczna Diffiego–Hellmana. Użycie tych algorytmów gwarantuje, że sekretne klucze symetryczne utworzone dla każdej sesji pozostaną bezpieczne, nawet wtedy, jeśli długoterminowe klucze publiczny i prywatny używane podczas protokołu handshake zostaną wykradzione.

Jeśli jakikolwiek z kroków przedstawionych powyżej się nie powiedzie, to połączenie jest anulowane. Druga faza komunikacji, Record Protocol, nie jest rozpoczynana.

Negocjowanie parametrów sesji przy pomocy algorytmów asymetrycznych jest stosunkowo kosztowną procedurą. Z tego powodu, zamiast tworzyć nowy klucz symetryczny, każda ze stron może spróbować odnowić poprzednio wykorzystywaną sesję. Jeśli druga strona zaakceptuje przywrócenie poprzedniej sesji, to komunikacja będzie szyfrowana przy pomocy wykorzystywanego w niej sekretnego klucza.

Bezpieczne połączenie TLS/SSL może być skonfigurowane z wykorzystaniem różnych symetrycznych i asymetrycznych algorytmów. Siła zabezpieczenia zależy więc w dużym stopniu od wybranego szyfru i poprawności jego implementacji.

Dwie pierwsze wersji protokołu SSL są generalnie uważane za niewystarczająco bezpieczne. Natomiast trzecia wersja SSL jest w swojej sile podobna do TLS 1.1. Nowsze wersje TLS są dużo bardziej dopracowane i zapewniają znacznie lepszy poziom zabezpieczeń. Mimo iż istnieje szereg ataków skierowanych na różne implementacje różnych algorytmów wchodzących w skład TLS, cały zestaw protokołów TLS jest uważany za skuteczne i efektywne narzędzie zapewniania bezpieczeństwa podczas komunikowania się przez sieci komputerowe.

Zaleca się, aby sekretne klucze były negocjowane przy użyciu algorytmów zapewniających poufność doskonałą (ang. perfect forward secrecy). Gwarantuje to, że nawet w przypadku skompromitowania kluczy prywatnych (należących na przykład od zaufanych Dostawców Certyfikatów), zabezpieczenia chronionych przez nie poszczególnych sesji nie zostaną złamanie. Organizacje Dostawców Certyfikatów były w ostatnim czasie celami wielu ataków, które doprowadziły do ujawnienia wielu długoterminowych kluczy prywatnych oraz skompromitowania wielu cyfrowych certyfikatów.

IRC jest protokołem warstwy aplikacji, który pozwala wymieniać wiadomości tekstowe pomiędzy użytkownikami.

Protokół został stworzony w roku 1988 przez fińskiego programistę, Jarkko Oikarinen. Miał umożliwić grupową komunikację za pomocą różnych forów dyskusyjnych, nazywanych kanałami (ang. channels), ale pozwalał również wysyłać i odbierać prywatne wiadomości oraz dane.

IRC działa zgodnie z modelem klient-serwer. Każdy użytkownik musi zainstalować aplikację kliencką. Za pomocą tej aplikacji jest możliwe wysyłanie wiadomości tekstowych na serwer IRC, który przesyła je do innych klientów. Serwery są połączone ze sobą i tworzą większe grupy, aby móc wymieniać wiadomości między sobą.

Dodatkowo, IRC oferuje dodatkowe serwisy. Najpopularniejszymi z nich są boty (wysyłające wiadomości generowane przez programy komputerowe na wskazane kanały) i tzw. bouncers, czyli procesy działające w tle, które dostarczają wiadomości do użytkowników offline lub do komputerów bez zainstalowanych klientów IRC.

Schemat poniżej przedstawia budowę przykładowej sieci IRC:

IRC zwykle działa na protokole TCP. Oficjalnym portem TCP przypisanym do IRC jest 194, jednakże zwykle preferuje się wyższe numery portów, w celu uniknięcia konieczności uruchamiania aplikacji z uprawnieniami administratora. Najpopularniejszymi portami dla IRC jest więc port 6667/TCP razem z kilkoma kolejnymi (6660-6669 i 7000).

Specyfikacja IRC jest zawarta w kilku dokumentach, RFC 1459 oraz późniejszych: RFC 2811, RFC 2812 i RFC 2813. Należy jednak zauważyć, że wspomniane dokumentacje nie są ściśle przestrzegane przez większość aplikacji klienckich i serwerowych.

IRC został zaprojektowany do przesyłania wiadomości tekstowych. Z początku, każdy znak był kodowany przy pomocy 8 bitów, bez wskazywania typu użytego kodowania. Powodowało to oczywiście problemy, kiedy komunikujący się użytkownicy używali różnych kodowań. Obecnie, najpopularniejszym kodowaniem w IRC jest UTF-8, które jest wykorzystywane przez większość aplikacji IRC.

Użytkownicy IRC komunikują się z serwerem i innymi użytkownikami za pomocą prostych komend tekstowych. Każda komenda określa kto jest jej odbiorcą (serwer, kanał lub inny użytkownik) oraz dodatkowe parametry, do których zalicza się również tekst wiadomości.

IRC był zaprojektowany w sposób, który nie zapewniał dużego poziomu zabezpieczeń. Większość serwerów nie wymaga od użytkowników rejestrowania kont i zwykle możliwe jest wybranie nazwy bezpośrednio przed dołączeniem do kanału.

Każdy proces zmieniania struktury sieci jest zwykle problematyczny i może powodować różne błędy (na przykład, jeśli kilku użytkowników ma takie same nazwy, ale różne uprawnienia). Ponadto, zakłada się, że serwery ufają sobie wzajemnie podczas wymieniania wiadomości. Zachowujący się błędnie serwer, mógłby spowodować niewłaściwe działanie całej sieci IRC.

Na początku pierwszej dekady XXI wieku wiele sieci IRC było atakowanych za pomocą ataków DDoS i innych, podobnych, bardziej skomplikowanych ataków. Spowodowało to ucieczkę użytkowników do innych sieci IRC lub nawet porzucenie tej formy komunikowania się w zupełności.

Ograniczenia protokołu są obecnie powszechne znane. Dlatego wiele nowoczesnych implementacji IRC wprowadziło szereg ulepszeń, mających podnieść bezpieczeństwo stosowania. Wiele serwerów IRC stosuje również bezpiecznie połączenia bazujące na SSL/TLS.

IRC był najbardziej popularny w roku 2003. Szacuje się, że był wtedy używany przez ponad milion ludzi na setkach tysiącach kanałów. Obecnie, liczba użytkowników zmniejszyła się do mniej niż pół miliona w roku 2014. Zmieniły się również powody, dla których ludzie używają aplikacji IRC.

Początkowo sieci IRC były wykorzystywane głównie w calach towarzyskich, do kontaktów między ich użytkownikami. Obecnie, funkcje te przejęły strony internetowe typu Facebook lub Twitter. Kanały IRC były wykorzystywane do wymieniania nielegalnych lub karalnych wiadomości i informacji, ale w dzisiejszych czasach istnieją lepsze sposoby robienia takich rzeczy (z siecią TOR na czele). IRC było wykorzystywane do rozpowszechniania pirackiego oprogramowania. Obecnie technologie typu P2P umożliwiają dużo sprawniejszą wymianę danych tego typu.

Z powodu postępującej komercjalizacji Internetu, wiele firm zdecydowało się zainwestować pieniądze w swoje własne produkty i utworzyć własne sposoby komunikowania się, niezależne od publicznie dostępnych sieci IRC. Z drugiej strony, powstało szereg komercyjnych lub otwartych projektów, które są stosowane przez zespoły programistów i różne firmy do prywatnej lub publicznej komunikacji.

IRC jest bardzo starym protokołem, będącym w użyciu przez wiele lat. Jego przeznaczenie zmieniało się w przeciągu tego okresu. Można spodziewać się, że technologia IRC będzie wciąż wykorzystywana przez przeróżne aplikacje i serwisy przez szereg nadchodzących lat.