Czy nagłówki HTTPS są szyfrowane?

598

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.

Dan Herbert
źródło
9
Nagłówki HTTP przez HTTPS są szyfrowane, a także nie są kompresowane przez HTTP (nawet jeśli treść jest). To czyni ich mniej podatnymi na ataki związane z kompresją, takie jak BEAST
Neil McGuigan

Odpowiedzi:

551

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).

Greg
źródło
3
@Greg, Ponieważ brama vhosta jest autoryzowana, Czy brama nie mogła ich odszyfrować, obserwować nagłówka Hosta, a następnie ustalić, do którego hosta wysłać pakiety?
Pacerier,
2
Sam Afaik URL nie jest szyfrowany.
Teddy
4
@Teddu co rozumiesz przez „sam adres URL nie jest szyfrowany”. Jest zaszyfrowany, ponieważ jest częścią nagłówka.
Dmitry Polushkin
1
Jeśli Fiddler jest używany do przechwytywania komunikacji https, nadal wyświetla niektóre nagłówki, dlaczego? Zwłaszcza, gdy połączenie internetowe odbywa się za pośrednictwem serwera proxy, który wymaga uwierzytelnienia, wyświetla nagłówek Proxy-Authorization, gdy żądanie zostanie ponownie wysłane po otrzymaniu 407 przy pierwszym wysłaniu.
Bochen Lin
1
@ Bochen w taki sam sposób jak Pegasus. Jeśli jesteś na dowolnym końcu tunelu HTTPS, możesz zobaczyć wszystko. W ten sam sposób widzę wszystko w devtools przeglądarki.
Nux
97

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.

mdb
źródło
4
Nie wszystkie ustawienia SSL wymagają DH
Dori
30
Mówiąc trochę pedantycznie: adres IP klienta i serwera, nazwa hosta serwera oraz sygnały o ich implementacjach SSL są przydatne dla podsłuchujących i są widoczne.
poolie
66

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.

Andrew Jennings
źródło
20
Wiem, że dobre odpowiedzi są na górze, ale to ponownie wprowadza błędne informacje. Domena nie jest widoczna, chyba że użyje się SNI. Protokół inny niż IP i TCP nie są widoczne. Nie możesz powiedzieć, czy używam HTTP 1.1, SPDY czy HTTP2. To, co jest widoczne na dwóch punktach końcowych, jest nieistotne, ponieważ celem szyfrowania nie jest uczynienie rzeczy niewidocznymi, ale uczynienie rzeczy widocznymi tylko dla zaufanych stron. Punkty końcowe są sugerowane w pytaniu i około 2/3 twojej odpowiedzi można usunąć. Informacje o serwerze proxy powinny być następujące: jeśli używasz serwera proxy HTTPS, ma on dostęp do wszystkiego .
Melvyn
6
Twój link mówi w szczególności, że pliki cookie są szyfrowane: „Połączenie użytkownika jest szyfrowane, zasłaniając adresy URL, pliki cookie i inne poufne metadane”.
DylanYoung
1
Tak to jest poprawne. Pliki cookie są szyfrowane podczas przesyłania, ale gdy dotrą do przeglądarki, nie są szyfrowane przez protokół SSL. Deweloper może zaszyfrować dane cookie, ale nie dotyczy to protokołu SSL.
Andrew Jennings,
4
@DylanYoung SSL = bezpieczna warstwa gniazda ; TLS = bezpieczeństwo warstwy transportowej . Szyfrowanie odbywa się na poziomie gniazda (połączenia) lub w inny sposób na poziomie transportu, a nie podczas przechowywania w przeglądarce dla bazy danych domeny.
ciekawy,
@Wigwam Wrażliwe na bezpieczeństwo pliki cookie HTTP są prawie zawsze nieprzejrzystymi odniesieniami (zwykle jest to liczba losowa silna pod względem kryptograficznym) do rekordu w bazie danych serwera uwierzytelnionych sesji. Jako takie szyfrowanie tego bezsensownego identyfikatora w większości przyniosłoby dodatkową złożoność.
ciekawy,
53

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.

Zachłanny
źródło
Kiedy CONNECT jest używany do tworzenia tunelu SSL?
ciekawy,
47

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

Więc wszystko w żądaniu jest szyfrowane.

strzałka do dmuchawki
źródło
Skoro SSL odbywa się w warstwie transportowej, a przypisanie adresu docelowego w pakietach (w nagłówku) odbywa się w warstwie sieci (która jest poniżej transportu), to w jaki sposób nagłówki są szyfrowane?
Prateek Joshi
@PrateekJoshi Ponieważ nagłówki HTTP znajdują się w warstwie aplikacji, a więc są domyślnie szyfrowane z powodu szyfrowania warstwy dolnej / nadrzędnej.
Aquarelle
40

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

CMS
źródło
21

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

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

naciśnięcie klawisza
źródło
37
Wikipedia nie jest specyfikacją, którą powinieneś cytować.
Aran Mulholland,
8

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

XXIAO
źródło
Nawet jeśli SNI nie jest obsługiwany, pośrednik zdolny do przechwytywania połączeń HTTP często będzie również w stanie monitorować pytania DNS (większość przechwytywania odbywa się w pobliżu klienta, jak na pirackim routerze użytkownika). Dzięki temu będą mogli zobaczyć nazwy DNS.
ciekawy,