Czy nagłówki HTTPS są szyfrowane?

Wysyłając dane przez HTTPS, wiem, że treść jest szyfrowana, jednak słyszę mieszane odpowiedzi na temat tego, czy nagłówki są szyfrowane, czy jaka część nagłówka jest szyfrowana.

Ile nagłówków HTTPS jest szyfrowanych?

W tym adresy URL żądania GET / POST, pliki cookie itp.

Cała partia jest szyfrowana ^† - wszystkie nagłówki. Dlatego SSL na vhostach nie działa zbyt dobrze - potrzebujesz dedykowanego adresu IP, ponieważ nagłówek hosta jest zaszyfrowany.

^† Standard identyfikacji nazwy serwera (SNI) oznacza, że ​​nazwa hosta może nie być szyfrowana, jeśli używasz TLS. Niezależnie od tego, czy używasz SNI, czy nie, nagłówki TCP i IP nigdy nie są szyfrowane. (Gdyby tak było, twoje pakiety nie byłyby routowalne).

Nagłówki są całkowicie zaszyfrowane. Jedyne informacje przesyłane przez sieć „w czystej formie” dotyczą konfiguracji SSL i wymiany kluczy D / H. Wymiana ta jest starannie zaprojektowana, aby nie dostarczać żadnych użytecznych informacji podsłuchującym, a po jej zakończeniu wszystkie dane są szyfrowane.

Przykro mi, nowa odpowiedź na stare pytanie. Myślałem, że dodam moje 0,02 $

OP zapytał, czy nagłówki zostały zaszyfrowane.

Są to: w drodze.

NIE są: gdy nie są w tranzycie.

Tak więc adres URL twojej przeglądarki (i tytuł, w niektórych przypadkach) może wyświetlać kwerendę (która zwykle zawiera najbardziej wrażliwe szczegóły) i niektóre szczegóły w nagłówku; przeglądarka zna pewne informacje nagłówka (typ zawartości, kod Unicode itp.); a historia przeglądarki, zarządzanie hasłami, ulubione / zakładki i strony w pamięci podręcznej będą zawierały kwerendę. Dzienniki serwera na zdalnym końcu mogą również zawierać kwerendę, a także niektóre szczegóły dotyczące zawartości.

Ponadto adres URL nie zawsze jest bezpieczny: domena, protokół i port są widoczne - w przeciwnym razie routery nie wiedzą, gdzie wysłać żądania.

Ponadto, jeśli masz serwer proxy HTTP, serwer proxy zna adres, zwykle nie zna pełnego zapytania.

Jeśli więc dane się przenoszą, są one ogólnie chronione. Jeśli nie jest w transporcie, nie jest szyfrowany.

Nie wybieraj nitów, ale dane na końcu są również odszyfrowywane i mogą być parsowane, czytane, zapisywane, przekazywane lub odrzucane do woli. Ponadto złośliwe oprogramowanie na obu końcach może wykonywać migawki danych wchodzących (lub wychodzących) z protokołu SSL - takich jak (zły) Javascript wewnątrz strony w HTTPS, który może potajemnie wywoływać połączenia HTTP (lub https) z witrynami logowania (od czasu dostępu do lokalnego dysku twardego) jest często ograniczony i nieprzydatny).

Pliki cookie również nie są szyfrowane w ramach protokołu HTTPS. Programiści, którzy chcą przechowywać poufne dane w plikach cookie (lub gdziekolwiek indziej), muszą użyć własnego mechanizmu szyfrowania.

Jeśli chodzi o buforowanie, większość współczesnych przeglądarek nie buforuje stron HTTPS, ale fakt ten nie jest zdefiniowany przez protokół HTTPS, jest całkowicie zależny od twórcy przeglądarki, aby mieć pewność, że nie buforuje stron otrzymanych przez HTTPS.

Więc jeśli martwisz się wąchaniem pakietów, prawdopodobnie nic ci nie jest. Ale jeśli martwisz się złośliwym oprogramowaniem lub kimś przeglądającym Twoją historię, zakładki, pliki cookie lub pamięć podręczną, jeszcze nie zabrakło Ci wody.

Wersja HTTP 1.1 dodała specjalną metodę HTTP CONNECT - przeznaczoną do utworzenia tunelu SSL, w tym niezbędnego uzgodnienia protokołu i konfiguracji kryptograficznej.
Następnie wszystkie zwykłe żądania są pakowane w tunel SSL, nagłówki i treść włącznie.

W przypadku SSL szyfrowanie odbywa się na poziomie transportu, więc odbywa się przed wysłaniem żądania.

Więc wszystko w żądaniu jest szyfrowane.

HTTPS (HTTP przez SSL) wysyła całą zawartość HTTP przez tunel SSL, więc treść HTTP i nagłówki są również szyfrowane.

Tak, nagłówki są szyfrowane. Jest napisane tutaj .

Wszystko w wiadomości HTTPS jest szyfrowane, w tym nagłówki oraz ładowanie żądania / odpowiedzi.

adres URL jest również szyfrowany, tak naprawdę masz tylko adres IP, port, a jeśli SNI, nazwę hosta, która nie jest zaszyfrowana.