Czy dane GET są również szyfrowane w HTTPS?

Kiedy otrzymasz

https://encrypted.google.com/search?q=%s

%sZapytanie jest szyfrowane? A może po prostu odpowiedź? Jeśli tak nie jest, dlaczego Google miałoby udostępniać swoje publiczne treści również z szyfrowaniem?

Całe żądanie jest szyfrowane, łącznie z adresem URL, a nawet poleceniem ( GET). Jedyne, co może zebrać strona interweniująca, taka jak serwer proxy, to adres docelowy i port.

Należy jednak pamiętać, że pakiet Client Hello uzgadniania TLS może rozgłaszać w pełni kwalifikowaną nazwę domeny w postaci zwykłego tekstu za pośrednictwem rozszerzenia SNI (dzięki @hafichuk), które jest używane we wszystkich nowoczesnych przeglądarkach głównego nurtu, choć niektóre tylko w nowszych systemach operacyjnych.

EDYTUJ: (Ponieważ właśnie to dało mi odznakę „Dobra odpowiedź”, myślę, że powinienem odpowiedzieć na całe pytanie…)

Cała odpowiedź jest również zaszyfrowana; proxy nie mogą przechwycić żadnej jego części.

Google obsługuje wyszukiwania i inne treści przez https, ponieważ nie wszystkie z nich są publiczne, a możesz także chcieć ukryć część treści publicznych przed MITM . W każdym razie najlepiej pozwolić Google samemu odpowiedzieć .

Sam adres URL jest zaszyfrowany, więc parametry w ciągu zapytania nie są przenoszone przez sieć.

Należy jednak pamiętać, że adresy URL zawierające dane GET są często rejestrowane przez serwer WWW, podczas gdy dane POST rzadko tak. Więc jeśli planujesz zrobić coś takiego /login/?username=john&password=doe, nie rób tego; zamiast tego użyj POST.

HTTPS Ustanawia podstawowe połączenie SSL przed przesłaniem jakichkolwiek danych HTTP. Zapewnia to, że wszystkie dane URL (z wyjątkiem nazwy hosta, która jest używana do ustanowienia połączenia) są przenoszone wyłącznie w ramach tego zaszyfrowanego połączenia i są chronione przed atakami typu man-in-the-middle w taki sam sposób, jak wszelkie dane HTTPS.

Powyższe jest częścią BARDZO wyczerpującej odpowiedzi udzielonej przez Google Answers znajdującego się tutaj:

http://answers.google.com/answers/threadview/id/758002.html#answer

Część adresu URL po nazwie hosta jest wysyłana w bezpieczny sposób.

Na przykład https://somewhere.com/index.php?NAME=FIELD

/index.php?NAME=FIELDCzęść jest szyfrowana. Tak somewhere.comnie jest.

Wszystko jest zaszyfrowane, ale musisz pamiętać, że twoje zapytanie pozostanie w logach serwera i będzie dostępne dla różnych analizatorów logów itp. (Co zwykle nie ma miejsca w przypadku żądania POST).

Połączenie zostaje zaszyfrowane przed przesłaniem żądania. Więc tak, żądanie jest również szyfrowane, łącznie z ciągiem zapytania.

Tak, to jest bezpieczne. SSL szyfruje wszystko.

Fragment żądania POST:

POST /foo HTTP/1.1
... some other headers

Fragment żądania GET:

GET /foo?a=b HTTP/1.1
... some other headers

W obu przypadkach wszystko, co jest wysyłane przez gniazdo, jest szyfrowane. Fakt, że klient widzi parametry w swojej przeglądarce podczas żądania GET, nie oznacza, że ​​mężczyzna w środku zobaczy to samo.

Właśnie połączyłem się przez HTTPS ze stroną internetową i przekazałem kilka parametrów GET. Następnie użyłem Wireshark do podsłuchiwania sieci. Za pomocą protokołu HTTP adres URL jest wysyłany w postaci niezaszyfrowanej, co oznacza, że ​​mogę łatwo zobaczyć wszystkie parametry GET w adresie URL. Używając HTTPS, wszystko jest szyfrowane i nie mogę nawet zobaczyć, który pakiet jest poleceniem GET, nie mówiąc już o jego zawartości!

SSL odbywa się przed analizą nagłówka, co oznacza:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Żądanie wygląda mniej więcej tak (nie pamiętam dokładnej składni, ale powinno być wystarczająco blisko):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

Z tego powodu posiadanie różnych certyfikatów SSL dla kilku hostów na tym samym IP jest problematyczne, żądana nazwa hosta jest znana dopiero po odszyfrowaniu.

Żądanie GET jest szyfrowane podczas korzystania z protokołu HTTPS - w rzeczywistości właśnie dlatego zabezpieczone witryny internetowe muszą mieć unikalny adres IP - nie ma możliwości uzyskania zamierzonej nazwy hosta (lub katalogu wirtualnego) z żądania, dopóki nie zostanie odszyfrowane.