Protokoły HTTP i HTTPS – historia, różnice i zastosowania

Adres strony internetowej, który widzimy w pasku przeglądarki, zwykle rozpoczyna się od liter HTTP lub HTTPS. Choć na pierwszy rzut oka różni je tylko jedna litera, w rzeczywistości oznacza ona ogromną różnicę w sposobie przesyłania danych i poziomie bezpieczeństwa połączenia. Protokół HTTP jest podstawowym mechanizmem komunikacji w sieci WWW, natomiast protokół HTTPS to jego bezpieczna odmiana, zapewniająca szyfrowanie przesyłanych informacji.

Na co dzień większość użytkowników internetu nie zastanawia się nad tym, co oznaczają te skróty w adresie – przeglądarka i tak automatycznie je dodaje, a my skupiamy się na zawartości strony. Warto jednak wiedzieć, co kryje się za tymi literami, ponieważ wpływa to na bezpieczeństwo i prywatność naszych działań w sieci. Nawet jeśli nie zajmujemy się zawodowo informatyką, podstawowa wiedza o protokołach HTTP i HTTPS pozwoli lepiej zrozumieć, jak działa przeglądarka, dlaczego niektóre strony wyświetlają symbol kłódki, oraz kiedy należy zwrócić uwagę na brak zabezpieczeń.

W tym artykule przystępnie przedstawimy historię powstania protokołów HTTP i HTTPS, dokonamy porównania ich działania w prostych słowach, oraz zilustrujemy praktyczne przykłady ich zastosowania. Dzięki temu łatwiej zrozumiesz, czemu dodatkowa literka “s” w adresie strony ma tak duże znaczenie.

Historia protokołu HTTP

Początki sieci WWW i narodziny HTTP

Historia protokołu HTTP sięga końca lat 80. XX wieku i wiąże się nierozerwalnie z powstaniem World Wide Web. W 1989 roku naukowiec Tim Berners-Lee przedstawił w ośrodku CERN koncepcję globalnej sieci dokumentów hipertekstowych, która pozwalałaby naukowcom dzielić się informacjami. Aby urzeczywistnić tę wizję, potrzebny był sposób na przesyłanie takich dokumentów między komputerami w sieci – tak powstał protokół HTTP, czyli Hypertext Transfer Protocol. Stanowił on wspólny język komunikacji między przeglądarką internetową (klientem) a serwerem, umożliwiający żądanie i odbiór stron WWW.

Pierwsza wersja HTTP oznaczona numerem 0.9 została zaimplementowana około 1990 roku. Był to protokół bardzo prosty – tak prosty, że często nazywa się go „protokołem jednowierszowym”. Przeglądarka wysyłała do serwera pojedynczą komendę (np. żądanie pobrania danego dokumentu), a serwer odpowiadał przesyłając zawartość strony w postaci czystego tekstu. Nie istniały wtedy jeszcze żadne nagłówki, kody statusu czy skomplikowane metody zapytań. Mimo tych ograniczeń HTTP/0.9 spełnił swoje zadanie: pozwolił na wyświetlenie pierwszych stron internetowych i pokazał, że możliwe jest przesyłanie hipertekstu – dokumentów z osadzonymi odnośnikami – w rozproszonym środowisku sieciowym.

Rozwój protokołu HTTP: wersje 1.0 i 1.1

Wraz z rozwojem sieci w połowie lat 90. protokół HTTP musiał zostać rozbudowany, by sprostać coraz większym wymaganiom. W 1996 roku opublikowano specyfikację HTTP w wersji 1.0, która wprowadziła wiele udoskonaleń względem pierwotnej wersji. Pojawiła się obsługa nagłówków HTTP, dzięki którym przeglądarka i serwer mogły wymieniać dodatkowe informacje (np. o typie przesyłanych danych czy ustawieniach pamięci podręcznej). Wprowadzono także kody statusu odpowiedzi (takie jak słynny 404 Not Found czy 200 OK), które informowały, czy żądanie powiodło się. Ponadto HTTP/1.0 umożliwił użycie nowych metod zapytań, takich jak POST (pozwalającej przesyłać dane, np. z formularzy), obok podstawowej metody GET służącej do pobierania zasobów. Wszystkie te rozszerzenia uczyniły komunikację WWW bogatszą i bardziej elastyczną – przeglądarki mogły już wtedy wyświetlać nie tylko czysty tekst, ale i obrazy czy inne multimedia, wiedząc jakiego rodzaju dane otrzymały.

Niedługo później, bo już w 1997 roku, pojawiła się kolejna istotna aktualizacja protokołu – HTTP 1.1. Ta wersja, sformalizowana w dokumentach RFC w 1997 i zaktualizowana w 1999, stała się fundamentem działania sieci na wiele kolejnych lat. HTTP/1.1 przyniósł usprawnienia kluczowe dla wydajności: umożliwił utrzymywanie jednego połączenia dla wielu kolejnych żądań (tzw. połączenia wielokrotne, ang. persistent connections), co zmniejszało narzut czasowy przy pobieraniu licznych elementów strony (obrazów, stylów, skryptów). Wprowadzono także mechanizmy takie jak transfer z fragmentacją (chunked transfer), pozwalające na przesyłanie danych w kawałkach bez znajomości ich ostatecznej długości z góry. Dzięki tym ulepszeniom protokół HTTP/1.1 lepiej radził sobie z coraz bardziej złożonymi stronami internetowymi i aplikacjami webowymi. W praktyce HTTP/1.1 zdominował komunikację w sieci WWW na przeszło dwie dekady – od końca lat 90. aż do połowy drugiej dekady XXI wieku większość stron działała właśnie w oparciu o tę wersję protokołu.

Nowoczesne wersje protokołu: HTTP/2 i HTTP/3

Po wielu latach dominacji wersji 1.1, nastąpiła era dalszych usprawnień protokołu HTTP, podyktowana potrzebą jeszcze szybszego ładowania stron i obsługi rosnącego ruchu w sieci. W 2015 roku oficjalnie opublikowano specyfikację HTTP/2 – pierwszej poważnej zmiany protokołu od czasów HTTP/1.1. Nowa wersja została zainspirowana wcześniejszym eksperymentalnym projektem SPDY rozwijanym przez Google. HTTP/2 znacząco poprawiło wydajność komunikacji: wprowadziło możliwość przesyłania wielu zapytań i odpowiedzi jednocześnie w ramach jednego połączenia (tzw. multiplexing), co usuwało ograniczenie „jedna odpowiedź na raz” z HTTP/1.x. Ponadto zastosowano kompresję nagłówków i ogólnie bardziej efektywny format przesyłania danych, dzięki czemu strony internetowe mogły ładować się szybciej, zwłaszcza te zawierające wiele elementów. Warto dodać, że przeglądarki internetowe zaimplementowały HTTP/2 praktycznie wyłącznie w połączeniu z HTTPS – nowe funkcje protokołu dostępne są tylko na szyfrowanych połączeniach. To posunięcie dodatkowo zachęciło właścicieli witryn do przejścia na HTTPS, aby móc korzystać z lepszej wydajności.

Kolejnym krokiem naprzód jest HTTP/3, nad którym prace rozpoczęto pod koniec drugiej dekady XXI wieku, a standaryzacja nastąpiła w roku 2022. HTTP/3 korzysta z zupełnie nowego podejścia do transportu danych, bazując na protokole QUIC (opracowanym m.in. przez Google), który z kolei działa w oparciu o UDP zamiast TCP. Dla przeciętnego użytkownika techniczne szczegóły nie są istotne – ważne jest to, że HTTP/3 jeszcze bardziej przyspiesza nawiązywanie połączeń i przesyłanie danych, eliminując pewne opóźnienia obecne w poprzednich wersjach. Podobnie jak HTTP/2, wersja HTTP/3 domyślnie działa w połączeniach szyfrowanych i z założenia jest projektowana tak, by zapewniać prywatność oraz bezpieczeństwo. Współcześnie (lata 2020+) coraz więcej popularnych serwisów i przeglądarek obsługuje HTTP/3, choć dla użytkownika końcowego zmiana ta jest niewidoczna i odbywa się automatycznie, w ramach znanego schematu adresu https://.

Historia protokołu HTTPS

Pierwsze kroki ku bezpiecznej komunikacji (SSL i początki HTTPS)

Od początku istnienia HTTP zdawano sobie sprawę, że jego otwarty charakter niesie pewne ryzyko – wszystkie dane przesyłane w ten sposób mogą zostać przechwycone przez osoby trzecie. Wraz z popularyzacją Internetu w połowie lat 90. zaczęto więc poszukiwać sposobu na zabezpieczenie komunikacji między przeglądarką a serwerem. Kluczowym momentem był rok 1994, kiedy firma Netscape (znana z przeglądarki Netscape Navigator) opracowała pierwszą wersję protokołu SSL (Secure Sockets Layer). SSL dodawał warstwę szyfrowania do połączenia sieciowego tak, aby dane HTTP mogły być przesyłane w formie zaszyfrowanej. Innymi słowy, stworzono mechanizm tunelowania protokołu HTTP wewnątrz bezpiecznego kanału – to właśnie wtedy narodziło się HTTPS (czasem interpretowane jako HTTP Secure lub HTTP over SSL), czyli szyfrowana odmiana komunikacji webowej.

Pierwsze wersje protokołu SSL (oznaczone numerami 2.0 w 1995 roku i 3.0 w 1996) stworzyły podstawy dla bezpiecznych połączeń w sieci. W początkowym okresie istniały jednak pewne ograniczenia prawne dotyczące stosowania silnej kryptografii – np. rząd USA limitował eksport oprogramowania szyfrującego z kluczami powyżej określonej długości. Z tego powodu pierwsze przeglądarki poza USA korzystały z osłabionych wersji szyfrowania. Te restrykcje zostały zniesione pod koniec lat 90., co otworzyło drogę do powszechnego stosowania mocnych algorytmów szyfrujących w protokole TLS na całym świecie. Ustalono też osobny numer portu 443 dla połączeń HTTPS (podczas gdy zwykłe HTTP używa portu 80). Dzięki temu przeglądarki mogły rozpoznać, kiedy nawiązywać połączenie szyfrowane. W drugiej połowie lat 90. protokół HTTPS zaczęto wykorzystywać przede wszystkim tam, gdzie wymagana była poufność – na stronach banków, w systemach płatności online, sklepach internetowych do przesyłania numerów kart kredytowych, oraz przy logowaniu użytkowników. Tego typu bezpieczne połączenie było wtedy nowinką i stosowano je oszczędnie, ze względu na dodatkowe obciążenie i koszty wdrożenia certyfikatów.

Od SSL do TLS – ewolucja bezpieczeństwa w sieci

Protokół SSL w kolejnych latach był rozwijany i standaryzowany przez społeczność internetową pod nową nazwą TLS (Transport Layer Security). W 1999 roku wydano TLS 1.0 jako następcę SSL 3.0 – zmieniono nazwę, aby podkreślić otwarty standard i pewne ulepszenia bezpieczeństwa, ale zasada działania pozostała podobna. Od tamtej pory pojawiły się kolejne wersje: TLS 1.1, 1.2, a w 2018 roku TLS 1.3, które przynosiły coraz silniejsze szyfry i usprawnienia (na przykład szybsze ustalanie wspólnego sekretu podczas nawiązywania połączenia). Dla użytkownika korzystającego z przeglądarki zmiany te są niemal niezauważalne – nadal widzi on tylko, że strona używa HTTPS i jest zabezpieczona. Warto jednak wspomnieć, że często w mowie potocznej nadal używa się terminu SSL (np. „certyfikat SSL”), mimo że współczesne zabezpieczenia technicznie opierają się na protokole TLS. Termin HTTPS obejmuje zarówno dawne połączenia SSL, jak i nowsze TLS – kluczowe jest to, że połączenie jest szyfrowane i zaufane niezależnie od konkretnej wersji protokołu.

Upowszechnienie protokołu HTTPS

Przez wiele lat po wprowadzeniu HTTPS stosowano go wybiórczo – jedynie tam, gdzie to absolutnie konieczne. Na zwykłych stronach informacyjnych czy forach internetowych przez długi czas wystarczał niezabezpieczony HTTP. Jednak z biegiem lat rosła świadomość zagrożeń związanych z przesyłaniem danych w jawnej postaci. Na początku XXI wieku dochodziło do coraz większej liczby ataków polegających na przechwytywaniu sesji użytkowników (tzw. sniffing lub sidejacking), co skłoniło duże serwisy do szerszego zastosowania szyfrowania. Na przykład już około 2010 roku usługodawcy tacy jak Google czy Facebook zaczęli domyślnie szyfrować całe sesje użytkowników (np. pocztę Gmail, połączenie z Facebookiem), a nie tylko strony logowania. Był to sygnał, że prywatność użytkowników sieci powinna być chroniona nieustannie, a nie tylko okazjonalnie.

Drugim przełomowym momentem było uruchomienie inicjatyw ułatwiających wdrożenie HTTPS dla właścicieli wszystkich stron, nie tylko tych największych. W 2014 roku powstała organizacja Let’s Encrypt, która zaczęła wydawać darmowe certyfikaty SSL/TLS automatycznie i bez opłat. Dzięki temu zniknęła bariera kosztów i skomplikowanych formalności – każdy administrator mógł w prosty sposób uzyskać certyfikat dla swojej domeny. Równocześnie firmy technologiczne mocno promowały ideę „HTTPS wszędzie”. Przeglądarka Google Chrome w kolejnych aktualizacjach (około 2017–2018) zaczęła wyraźnie ostrzegać użytkowników przed stronami bez szyfrowania, oznaczając je jako „Niezabezpieczone”. Wyszukiwarki internetowe także wprowadziły zachęty: Google ogłosił, że witryny dostępne przez HTTPS mogą liczyć na minimalnie lepsze traktowanie w wynikach wyszukiwania (co motywowało branżę SEO do migracji na HTTPS). Wszystkie te czynniki sprawiły, że pod koniec drugiej dekady XXI wieku nastąpił masowy wzrost wdrożeń HTTPS. Obecnie zdecydowana większość ruchu w sieci web jest szyfrowana – szacuje się, że ponad 80–90% odwiedzin stron w popularnych przeglądarkach odbywa się przez HTTPS. Innymi słowy, bezpieczne połączenie stało się normą, a witryny pozostające przy starym HTTP stanowią wyjątek od reguły.

Jak działa protokół HTTP?

Zapytanie i odpowiedź – model klient–serwer

Protokół HTTP działa w klasycznym modelu klient–serwer. Oznacza to, że jedna ze stron (klient, np. Twoja przeglądarka internetowa) wysyła żądanie do drugiej strony (serwera), a serwer przygotowuje odpowiedź i odsyła ją klientowi. W praktyce, gdy wpisujesz adres URL i naciskasz Enter, przeglądarka nawiązuje połączenie z serwerem danej strony i wysyła mu zapytanie HTTP, informując, jaki konkretny zasób chce pobrać (np. określoną stronę HTML, obrazek czy inny plik).

Żądanie to ma formę tekstową – zawiera m.in. metodę (taką jak GET dla pobrania danych czy POST dla wysłania danych formularza) oraz adres żądanego zasobu. Serwer po otrzymaniu prośby odnajduje odpowiedni plik lub generuje treść i wysyła z powrotem odpowiedź HTTP. Odpowiedź również ma postać tekstową: zaczyna się od kodu statusu (np. 200 OK, gdy wszystko poszło dobrze, lub 404, gdy zasób nie został znaleziony), a następnie zawiera żądane dane (np. treść strony w języku HTML). Taki cykl żądanie–odpowiedź stanowi podstawę działania całej sieci WWW opartej na protokole HTTP.

Bezstanowość HTTP i mechanizmy sesji

Warto zauważyć, że HTTP jest protokołem bezstanowym. Oznacza to, że po zrealizowaniu pojedynczego żądania i przesłaniu odpowiedzi serwer nie „pamięta” niczego na temat tego, kto się z nim łączył ani co wcześniej zostało przesłane. Każde połączenie HTTP jest niezależne – tak jakby za każdym razem klient nawiązywał kontakt z serwerem po raz pierwszy. Taka prostota była zamierzona, bo ułatwia skalowanie usług (serwer nie musi przechowywać informacji o setkach czy milionach użytkowników między kolejnymi kliknięciami).

Z drugiej strony brak pamięci o poprzednich interakcjach utrudnia realizację pewnych funkcjonalności, takich jak utrzymywanie stanu zalogowania użytkownika czy zawartości koszyka w sklepie internetowym. Rozwiązaniem stały się dodatkowe mechanizmy ponad protokołem HTTP – przede wszystkim ciasteczka (cookies) wprowadzone po stronie przeglądarki. Cookie to mały fragment danych, który serwer może przekazać przeglądarce przy odpowiedzi (np. unikalny identyfikator sesji), a przeglądarka automatycznie dołącza ten identyfikator do kolejnych żądań kierowanych do tego samego serwera. Dzięki temu serwer „rozpoznaje”, że kolejne żądania pochodzą od tego samego użytkownika i może utrzymać ciągłość sesji (wie np., że dana osoba jest już zalogowana albo jakie ma ustawienia). Mechanizm ten stał się nieodłączną częścią działania nowoczesnych aplikacji webowych, choć jest formalnie dodatkiem wykraczającym poza podstawowy protokół HTTP.

Jak działa protokół HTTPS?

Certyfikat SSL/TLS – tożsamość i zaufanie

Aby nawiązać bezpieczne połączenie HTTPS, serwer musi przedstawić przeglądarce certyfikat SSL/TLS. Taki certyfikat to cyfrowy dokument potwierdzający tożsamość serwera (witryny internetowej). Zawiera on m.in. nazwę domeny strony oraz klucz publiczny potrzebny do ustanowienia szyfrowanego połączenia, a całość jest cyfrowo podpisana przez zaufaną instytucję – tzw. Urząd Certyfikacji (ang. Certificate Authority).

Przeglądarka, otrzymując certyfikat od serwera, weryfikuje czy został on wystawiony przez urząd znajdujący się na liście zaufanych (przeglądarki i systemy operacyjne posiadają wbudowane listy uznanych urzędów) oraz czy nazwa domeny w certyfikacie odpowiada faktycznej stronie, z którą nawiązywane jest połączenie. Jeśli certyfikat jest prawidłowy i ważny (nie wygasł ani nie został unieważniony), przeglądarka uznaje, że może zaufać danemu serwerowi. W praktyce oznacza to pewność, że rzeczywiście komunikujemy się z tym, z kim zamierzaliśmy – np. z prawdziwą witryną banku, a nie z kimś podszywającym się pod nią. Certyfikat pełni więc rolę swoistego dowodu tożsamości dla strony internetowej, wydanego przez niezależny, wiarygodny podmiot.

Ustanowienie szyfrowanego połączenia (TLS handshake)

Po pomyślnej weryfikacji certyfikatu, przeglądarka i serwer uzgadniają szczegóły bezpiecznej komunikacji. Odbywa się to w procesie zwanym handshakiem TLS, czyli uzgadnianiem protokołu szyfrowania. W trakcie tego procesu ustalany jest wspólny tajny klucz szyfrowania, który posłuży do kodowania całej dalszej wymiany danych. Najprościej mówiąc, przeglądarka i serwer wymieniają między sobą informacje kryptograficzne (wykorzystując m.in. klucz publiczny serwera z certyfikatu) tak, aby obie strony ostatecznie dysponowały identycznym sekretnym kluczem, znanym tylko im.

Gdy klucz zostanie uzgodniony, rozpoczyna się właściwa, szyfrowana komunikacja. Od tego momentu wszelkie dane protokołu HTTP (żądania i odpowiedzi), które przeglądarka wysyła do serwera lub odbiera, są szyfrowane tym uzgodnionym kluczem. Osoba postronna, która przechwyci takie zaszyfrowane pakiety, nie będzie w stanie odczytać ich treści – zobaczy jedynie pozornie losowy ciąg znaków nie mający sensu bez klucza. Dodatkowo protokoły kryptograficzne dbają o integralność danych, co oznacza, że jeśli ktoś próbowałby zmodyfikować przesyłane informacje po drodze, zostanie to wykryte i połączenie zostanie przerwane. Użytkownik widzi efekty handshaku TLS w postaci symbolu zamkniętej kłódki obok adresu strony. Obecność kłódki oznacza, że połączenie zostało pomyślnie zaszyfrowane i zweryfikowane – od tego punktu cała wymiana danych jest chroniona przed podglądem lub manipulacją.

HTTP vs HTTPS – najważniejsze różnice

Podsumowując, choć HTTP i HTTPS służą do tego samego (przesyłania danych w sieci WWW), różnią się kilkoma kluczowymi aspektami:

• Szyfrowanie danych: Protokół HTTP przesyła dane w formie niezaszyfrowanej (jawnej). Oznacza to, że informacje (np. tekst strony, dane logowania) przemieszczają się przez internet w czytelnej postaci i jeśli ktoś je przechwyci, może je bez trudu odczytać. Protokół HTTP można przyrównać do wysyłania informacji na pocztówce – jej treść może przeczytać każdy, kto wejdzie w jej posiadanie. Natomiast HTTPS jest jak wysłanie listu w zaklejonej kopercie – tylko adresat może poznać jego zawartość, ponieważ cała transmisja zostaje zaszyfrowana między przeglądarką a serwerem. W efekcie dane są chronione przed podejrzeniem – nawet jeśli ktoś je przechwyci, zobaczy jedynie zaszyfrowany ciąg znaków, którego nie rozszyfruje bez odpowiedniego klucza.
• Weryfikacja tożsamości i zaufanie: HTTP nie zapewnia żadnego mechanizmu potwierdzania tożsamości serwera. Łącząc się przez HTTP, przeglądarka zakłada, że rozmawia z właściwym serwerem, ale nie ma na to kryptograficznego „dowodu” – jest podatna na ataki typu „podszywanie się”. W przypadku HTTPS serwer musi posiadać ważny certyfikat, który jest sprawdzany przez przeglądarkę. Dzięki temu użytkownik ma pewność, że nawiązał połączenie z prawdziwą, zaufaną witryną (a nie np. fałszywym portalem podstawionym przez hakera). Obecność kłódki i „https://” w adresie daje więc gwarancję autentyczności połączenia.
• Port i adres URL: Domyślny port nasłuchiwania dla HTTP to 80, natomiast dla HTTPS to 443. W praktyce przy wpisywaniu adresu URL nie musimy podawać portu – wystarczy użyć przedrostka „http://” lub „https://”, a przeglądarka sama domyśli się właściwego portu. Różnicę widać w samym adresie strony: HTTP na początku adresu (np. http://example.com) oznacza brak szyfrowania, zaś HTTPS (https://example.com) oznacza połączenie szyfrowane. Przeglądarki dodatkowo oznaczają strony HTTPS ikoną zamkniętej kłódki, a strony HTTP mogą być oznaczone jako „Niezabezpieczone”.
• Wydajność i szybkość: Niegdyś uważano, że szyfrowanie wprowadza znaczne opóźnienie i obciążenie. Rzeczywiście, protokół HTTPS wykonuje dodatkową pracę (uzgadnianie kluczy, szyfrowanie i deszyfrowanie danych), co technicznie czyni go nieco bardziej wymagającym niż czysty HTTP. Jednak dzięki postępowi technologicznemu różnice te są obecnie minimalne. Handshake TLS zajmuje ułamki sekund, a szyfrowanie/dekryptowanie danych jest bardzo szybkie dzięki optymalizacjom sprzętowym. W praktyce ładowanie strony przez HTTPS nie jest zauważalnie wolniejsze niż przez HTTP – zwłaszcza że nowoczesne protokoły jak HTTP/2 i HTTP/3, zwykle używane z HTTPS, usprawniają wiele aspektów transmisji danych i kompensują drobny narzut.
• Zastosowanie: HTTP bywa używany ewentualnie w sieciach lokalnych lub do publicznych treści, gdzie szyfrowanie uznano za zbędne. Jednak we współczesnym internecie większość witryn korzysta z HTTPS niezależnie od typu zawartości. HTTPS jest absolutnie wymagany wszędzie tam, gdzie przesyłane są dane wrażliwe (loginy, hasła, dane osobowe, płatności). Co więcej, wiele przeglądarek i usług sieciowych wymaga HTTPS do działania pewnych funkcji (np. geolokalizacji w aplikacjach webowych czy obsługi nowoczesnych API przeglądarki). Warto dodać, że współczesne przeglądarki blokują tzw. „mixed content”, czyli sytuację, gdy strona ładowana przez HTTPS próbuje doładować zasób (np. obraz lub skrypt) przez niezabezpieczony protokół HTTP. Przeglądarka uznaje to za potencjalne zagrożenie i część takiego niezabezpieczonego kontentu może zostać zablokowana. Dlatego współczesne strony dbają, by cała ich zawartość (każdy plik i odnośnik) również korzystały z HTTPS. Ponadto wyszukiwarki internetowe preferują strony działające na HTTPS – strona z certyfikatem SSL jest lepiej postrzegana pod względem bezpieczeństwa, a Google od 2018 roku oznacza brak HTTPS jako czynnik obniżający zaufanie użytkowników do witryny.

Zastosowanie protokołów HTTP i HTTPS w praktyce

Przeglądanie stron publicznych

W przypadku zwykłych stron informacyjnych, blogów czy serwisów newsowych, gdzie użytkownik głównie czyta treści bez podawania swoich danych, dawniej powszechnie używano protokołu HTTP. Nie przekazywano tam poufnych informacji, więc brak szyfrowania nie wydawał się dużym problemem. Jednak nawet przy takim biernym przeglądaniu treści, protokół HTTPS przynosi korzyści. Po pierwsze, chroni prywatność – osoby postronne (np. dostawca internetu czy administrator sieci Wi-Fi) nie zobaczą, jakie artykuły czytamy ani jakie strony odwiedzamy, jeśli są one szyfrowane. Po drugie, zapewnia integralność treści – mamy pewność, że to co wyświetla przeglądarka, pochodzi faktycznie z serwera danej witryny i nie zostało zmodyfikowane po drodze. W praktyce zdarzało się, że przy braku szyfrowania pośrednicy mogli wstrzykiwać własne treści (np. dodatkowe reklamy) do stron przesyłanych HTTP. HTTPS uniemożliwia takie działania. Dlatego obecnie nawet serwisy udostępniające wyłącznie publiczne treści coraz częściej stosują HTTPS, chcąc zagwarantować użytkownikom pełne zaufanie do prezentowanej informacji.

Logowanie i transakcje online

Wszelkie sytuacje, w których przesyłamy swoje dane osobiste, hasła czy informacje finansowe, muszą opierać się na protokole HTTPS. Gdy logujemy się na konto pocztowe, do bankowości internetowej czy dokonujemy płatności w sklepie online, szyfrowanie jest absolutnie niezbędne. Jeśli strona logowania lub formularz płatności nie korzysta z HTTPS, istnieje ogromne ryzyko, że wpisywane dane mogą zostać przechwycone przez osoby trzecie. Dlatego obecnie renomowane serwisy zawsze stosują HTTPS wszędzie tam, gdzie użytkownik wprowadza jakiekolwiek wrażliwe informacje. Przeglądarki również ostrzegają przed wpisywaniem haseł na niezabezpieczonych stronach. Jako użytkownicy powinniśmy zwracać na to uwagę – na stronie logowania do banku czy poczty musi widnieć symbol kłódki i adres zaczynający się od „https://”. Jeśli jest inaczej, należy przerwać procedurę i nie podawać danych, bo może to świadczyć o braku zabezpieczeń lub nawet o próbie oszustwa (np. fałszywa strona podszywająca się pod prawdziwą).

Publiczne sieci Wi-Fi a bezpieczeństwo

Korzystanie z publicznych, niezabezpieczonych sieci Wi-Fi (np. w kawiarniach, hotelach czy na lotniskach) doskonale pokazuje praktyczne różnice między HTTP a HTTPS. W otwartej sieci, gdzie ruch nie jest szyfrowany, korzystanie ze stron przez niezabezpieczony HTTP jest bardzo ryzykowne – inny uczestnik tej samej sieci może stosunkowo łatwo podsłuchiwać ruch sieciowy. Jeśli odwiedzamy strony przez HTTP, taka osoba może zobaczyć, jakie witryny przeglądamy, a nawet przechwycić nasze loginy czy inne dane wpisywane na tych stronach. Zdarzały się przypadki ataków, gdzie intruzi w publicznym Wi-Fi przejmowali sesje użytkowników na serwisach społecznościowych właśnie przez brak HTTPS. Z kolei korzystając ze stron zabezpieczonych HTTPS w takiej sieci, nadal jesteśmy chronieni – dane płyną zaszyfrowanym kanałem, więc nawet jeśli ktoś przechwyci pakiety, nie odczyta ich zawartości. Dlatego w sieciach publicznych należy unikać witryn, które nie oferują szyfrowania, lub przynajmniej nie wykonywać na nich żadnych czynności wymagających podania wrażliwych danych. Rozwój HTTPS sprawił, że dziś nawet łącząc się przez przypadkowe Wi-Fi, większość naszego ruchu (np. do wyszukiwarki, poczty, portali społecznościowych) jest z definicji szyfrowana, co znacząco podnosi bezpieczeństwo codziennego korzystania z internetu.

Nie tylko przeglądarki – zastosowanie HTTP(S) w innych aplikacjach

Choć na co dzień mówimy o protokołach HTTP i HTTPS głównie w kontekście przeglądania stron WWW, warto wiedzieć, że są one wykorzystywane znacznie szerzej. Wiele aplikacji mobilnych i programów komputerowych komunikujących się z serwerami w internecie również opiera swoją komunikację na HTTP lub HTTPS. Na przykład aplikacja pogodowa w telefonie, sprawdzająca aktualną prognozę, prawdopodobnie łączy się z serwerem dostawcy danych właśnie za pomocą zapytań HTTPS do określonego API (interfejsu programistycznego) na serwerze. Podobnie, usługi streamingowe, klienty pocztowe webmail (działające w przeglądarce) czy nawet urządzenia typu smart home (jak kamerki czy czujniki podłączone do chmury) często korzystają z protokołu HTTPS, aby bezpiecznie przesyłać informacje.

W tych przypadkach protokół HTTP/S działa tak samo jak w przeglądarce: jest warstwą komunikacji między klientem (aplikacją) a serwerem. Różnica jest tylko taka, że zamiast przeglądarki internetowej klientem może być inny program. Bezpieczeństwo zapewniane przez HTTPS jest równie istotne: chcemy mieć pewność, że np. nasza aplikacja bankowa w telefonie komunikuje się wyłącznie z prawdziwym serwerem banku i że przesyłane dane (np. saldo konta czy zlecenia przelewów) są zaszyfrowane i nie do przechwycenia. Standaryzacja komunikacji na HTTP/HTTPS ułatwia tworzenie rozmaitych usług internetowych, bo programiści i urządzenia mogą korzystać z powszechnie zrozumiałego protokołu, a dodanie warstwy szyfrowania dba o poufność i bezpieczeństwo tej komunikacji.

Ciekawostki

• Kod 404: Jednym z kodów odpowiedzi protokołu HTTP jest 404 (Not Found), oznaczający, że żądany zasób nie został znaleziony. Kod ten stał się na tyle rozpoznawalny, że przedostał się do kultury masowej – powiedzenie „404” bywa żartobliwie używane jako synonim „nie znaleziono” lub „brak odpowiedzi”.
• Żart o „imbryku” (418): Protokół HTTP posiada również nietypowy kod statusu 418 oznaczający… „I’m a teapot” („Jestem imbrykiem”). Ten żartobliwy kod pojawił się jako primaaprilisowy żart w dokumencie RFC 2324 (1998) jako część fikcyjnego protokołu parzenia kawy i herbaty HTTP. Choć nie jest używany na poważnie, bywa zaimplementowany dla zabawy w niektórych serwerach – stanowi ciekawostkę pokazującą luźniejsze akcenty w historii rozwoju protokołu.
• Pierwsza strona WWW: Historycznie pierwsza strona internetowa stworzona przez Tima Berners-Lee w 1991 roku (info.cern.ch) była udostępniana przez protokół HTTP. W tamtym czasie nie istniał jeszcze HTTPS, ponieważ nie było to potrzebne w ograniczonym środowisku naukowym. Dziś kopię tej pierwszej strony można wciąż obejrzeć w sieci – jest ona dostępna (już przez HTTPS) jako hołd dla początków sieci WWW.

Podsumowanie

Protokoły HTTP i HTTPS odegrały ogromną rolę w rozwoju i obecnym kształcie Internetu. HTTP, zaprojektowany na początku lat 90., umożliwił powstanie sieci World Wide Web i swobodne przekazywanie stron internetowych na całym świecie. Z kolei HTTPS, wprowadzony kilka lat później, zabezpieczył tę komunikację, czyniąc korzystanie z sieci znacznie bezpieczniejszym. Dziś trudno wyobrazić sobie codzienne użytkowanie internetu bez szyfrowanych połączeń – padlock obok adresu strony stał się normą, a brak tego symbolu wzbudza uzasadniony niepokój.

Warto podkreślić, że HTTPS nie zastępuje protokołu HTTP, lecz go uzupełnia. Można powiedzieć, że HTTPS to po prostu HTTP wzbogacony o warstwę szyfrowania TLS/SSL. Fundament komunikacji pozostał ten sam (żądania, odpowiedzi, metody takie jak GET/POST), ale dodano element zapewniający poufność i integralność danych. Ta dodatkowa „literka s” w adresie oznacza, że zarówno treść naszych wiadomości, jak i tożsamość serwera są chronione.

Obecnie zdecydowana większość witryn działa w oparciu o HTTPS, co jest korzystne dla nas wszystkich jako użytkowników. Dzięki temu nasze hasła, wiadomości i inne dane osobiste nie są przesyłane „otwartym tekstem” przez sieć, a ryzyko ataków typu podsłuch czy modyfikacja treści zostało zminimalizowane. Trend ten prawdopodobnie będzie się utrzymywał – protokół HTTP bez szyfrowania odchodzi stopniowo do lamusa. Jeśli napotkamy witrynę korzystającą jeszcze z samego HTTP, powinniśmy być ostrożni. Całe szczęście, wdrożenie HTTPS stało się dziś łatwe i dostępne nawet dla małych witryn, więc internet zmierza w kierunku pełnego zabezpieczenia ruchu. Możemy zatem cieszyć się wygodą korzystania z bogatych zasobów sieci, mając zarazem gwarancję prywatności i bezpieczeństwa, jaką daje protokół HTTPS. Mówiąc krótko: protokół HTTP to fundament komunikacji w sieci, a protokół HTTPS to jego nieodłączny strażnik bezpieczeństwa.