HTTP / HTTPS

HTTP (Hypertext Transfer Protocol) to protokół, którym przeglądarka prosi serwer o stronę lub dane, a serwer jej odpowiada. Działa w modelu żądanie–odpowiedź i jest bezstanowy — każde zapytanie traktuje osobno, bez pamięci o poprzednich. HTTPS (HTTP Secure) to ten sam protokół, ale przesyłany przez szyfrowany tunel TLS (Transport Layer Security). TLS dokłada poufność, integralność danych i potwierdzenie tożsamości serwera. HTTP używa domyślnie portu 80, a HTTPS portu 443. Cała różnica polega na tym, że HTTPS owija zwykły HTTP w warstwę szyfrowania.

Czym jest HTTP?

HTTP ustala, jak klient (zwykle przeglądarka) prosi o zasób i jak serwer odpowiada. Jest bezstanowy: każde żądanie jest niezależne, a to, że jesteś zalogowany albo masz coś w koszyku, pamiętają dodatkowe mechanizmy — ciasteczka, nagłówki autoryzacji, tokeny. Pojedynczy komunikat HTTP ma linię startową, nagłówki i opcjonalne ciało (właściwą treść).

Metody HTTP

• GET — pobranie zasobu (bez efektów ubocznych).
• POST — przesłanie danych do przetworzenia.
• PUT — utworzenie lub zastąpienie zasobu.
• PATCH — częściowa zmiana zasobu.
• DELETE — usunięcie zasobu.
• HEAD — jak GET, ale zwraca same nagłówki, bez ciała.
• OPTIONS — sprawdzenie, które metody są dozwolone (m.in. preflight CORS).
• CONNECT — zestawienie tunelu (typowo do serwera proxy dla HTTPS).

Kody statusu HTTP

• 1xx — informacyjne (np. 101 Switching Protocols).
• 2xx — sukces (200 OK, 201 Created, 204 No Content).
• 3xx — przekierowania (301 Moved Permanently, 302 Found, 304 Not Modified).
• 4xx — błędy po stronie klienta (400, 401, 403, 404, 429 Too Many Requests).
• 5xx — błędy po stronie serwera (500, 502, 503, 504).

Czym różni się HTTPS od HTTP?

HTTPS to HTTP przesyłany przez połączenie zabezpieczone protokołem TLS (następcą starszego SSL). TLS dokłada trzy rzeczy, których zwykły HTTP nie ma:

• Poufność — treść jest zaszyfrowana, więc ktoś podsłuchujący sieć (np. na publicznym Wi-Fi, u operatora, w punkcie pośredniczącym) nie odczyta ciała ani nagłówków HTTP, w tym ciasteczek i danych logowania.
• Integralność — jeśli dane zostaną po drodze podmienione, zostanie to wykryte (mechanizmy MAC/AEAD). Trudniej więc komuś z zewnątrz wstrzyknąć własną treść.
• Potwierdzenie tożsamości serwera — certyfikat X.509 podpisany przez urząd certyfikacji (CA, Certificate Authority) potwierdza, że łączysz się z właściwą domeną, a nie z podstawionym serwerem. To utrudnia atak man-in-the-middle, w którym napastnik wciska się między Ciebie a serwer.

W zwykłym HTTP wszystko leci tekstem jawnym: adres URL ze ścieżką i parametrami, nagłówki, ciasteczka i ciało. Każdy po drodze może to przeczytać lub zmienić. W HTTPS obserwator z zewnątrz widzi głównie: docelowy adres IP, port 443, przybliżone rozmiary i czasy pakietów oraz nazwę hosta (przez pole SNI w handshake i przez zapytania DNS — chyba że używa się szyfrowanego DNS i Encrypted Client Hello). Pełna ścieżka URL, parametry i sama treść pozostają zaszyfrowane.

Jak działa handshake TLS?

Zanim poleci pierwsze żądanie HTTP, obie strony ustalają zasady szyfrowania w tzw. handshake TLS (wymianie powitalnej):

1. Klient wysyła ClientHello z obsługiwaną wersją TLS, losową wartością i listą zestawów szyfrów (cipher suites).
2. Serwer odpowiada ServerHello, przesyła swój certyfikat i wybiera zestaw szyfrów.
3. Strony uzgadniają klucz sesji za pomocą kryptografii asymetrycznej (np. ECDHE, które daje forward secrecy — przechwycony dziś ruch nie da się odszyfrować nawet po wykradzeniu klucza w przyszłości).
4. Dalej komunikacja jest szyfrowana symetrycznie wspólnym kluczem sesji — to znacznie szybsze niż kryptografia asymetryczna.

TLS 1.3 skraca handshake do jednego round-tripa (a przy wznowieniu sesji do trybu 0-RTT), usuwa przestarzałe szyfry i wymusza forward secrecy. Gdy certyfikat wygasł, szyfr jest słaby albo nazwa hosta się nie zgadza, przeglądarka pokazuje błąd bezpieczeństwa.

Czym jest HSTS?

HSTS (HTTP Strict Transport Security) to nagłówek odpowiedzi (Strict-Transport-Security), który mówi przeglądarce: przez określony czas łącz się z tą domeną wyłącznie po HTTPS. Po jego zapamiętaniu przeglądarka sama zamienia http:// na https://, a żądanie HTTP w ogóle nie opuszcza urządzenia. Dzięki temu HSTS chroni przed atakami downgrade i SSL stripping, w których napastnik próbuje zepchnąć ofiarę z powrotem na nieszyfrowany HTTP. Domeny zgłoszone na listę HSTS preload są wymuszane na HTTPS już przy pierwszym połączeniu.

HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC)

Sama logika HTTP (metody, kody, nagłówki) jest stała, ale sposób przesyłania danych zmieniał się przez lata:

• HTTP/1.1 — protokół tekstowy z trwałymi połączeniami (keep-alive) i nagłówkiem Host (wiele domen na jednym IP). Ma problem head-of-line blocking: zaległe żądanie blokuje kolejne. Przeglądarki obchodzą to, otwierając kilka równoległych połączeń TCP do serwera.
• HTTP/2 — binarny zapis ramek, multipleksowanie (wiele strumieni w jednym połączeniu TCP) i kompresja nagłówków (HPACK). Znosi blokowanie na poziomie HTTP, ale utrata pakietu w TCP wciąż wstrzymuje wszystkie strumienie (blokowanie na poziomie transportu).
• HTTP/3 — działa nad QUIC (transport oparty na UDP z wbudowanym TLS 1.3). Strumienie są niezależne, więc znika blokowanie na poziomie transportu. Uzgodnienie połączenia i szyfrowania mieści się w jednym handshake (szybszy start), a connection migration utrzymuje sesję przy zmianie sieci (np. Wi-Fi → LTE). HTTP/3 jest zawsze szyfrowany.

Dlaczego HTTP/HTTPS są istotne dla bezpieczeństwa i monitoringu sieci?

HTTP/HTTPS to dziś najczęstszy ruch aplikacyjny w sieci. To dlatego jest zarazem głównym celem ataków i ważnym źródłem danych (telemetrii) dla zespołów SOC oraz systemów NDR/IDS.

• Powierzchnia ataku — wstrzyknięcia (SQLi, XSS), nadużycia API, web shelle i ataki na warstwę aplikacji idą przez HTTP. Nieszyfrowany HTTP pozwala podsłuchać dane logowania i ciasteczka sesji oraz podmienić treść w locie.
• Widoczność a szyfrowanie — HTTPS chroni użytkownika, ale ogranicza wgląd w treść dla monitoringu. Do wykrywania zagrożeń używa się więc metadanych warstwy 4, analizy pola SNI i certyfikatów, odcisków handshake (np. JA3/JA4), logów proxy oraz — tam gdzie to dozwolone i kontrolowane — deszyfracji TLS na bramie.
• Wykrywanie anomalii — nietypowe nagłówki User-Agent, podejrzane domeny w SNI, samopodpisane certyfikaty, łączność C2 (beaconing) ukryta w HTTPS, masowe kody 4xx/5xx czy nagły skok ruchu na porcie 443 to typowe sygnały dla NDR.
• Higiena konfiguracji — wymuszanie HTTPS (przekierowania, HSTS), wyłączanie starych wersji TLS i słabych szyfrów, poprawne certyfikaty oraz pilnowanie ich daty wygaśnięcia ograniczają ryzyko downgrade i przejęcia sesji.

Dowiedz się więcej

• ARP Spoofing – jak wykryć atak Man-in-the-Middle i zatruwanie ARP w sieci LAN — ARP spoofing może przechwytywać ruch HTTP i obniżać bezpieczeństwo sesji HTTPS.
• Monitoring sieci i network visibility – analiza ruchu sieciowego jako podstawa visibility cybersecurity — Monitoring sieci pomaga wykrywać ruch HTTP i oceniać jakość zabezpieczeń HTTPS.
• Czym jest NetFlow i jak ten protokół jest wykorzystywany w praktyce? — NetFlow pokazuje przepływy, także te z ruchu HTTP i HTTPS.
• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR dotyczy aplikacji webowych, gdzie żądania HTTP ujawniają błędy dostępu.