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


Odpowiedzi:


145

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


2
Jestem trochę niezadowolony z twierdzenia, że ​​adres URL jest zaszyfrowany. Czy nazwa hosta nie jest uważana za część adresu URL? Jeśli tak, stwierdzenie jest błędne. Nie ma możliwości ukrycia nazwy hosta / adresu IP przed serwerem ISP / proxy w taki sam sposób, w jaki nie można ukryć adresu docelowego podczas wysyłania fizycznej poczty.
Abhishek Anand

1
@Abhishek: nazwa hosta nie występuje w nagłówku TCP / IP. W mojej odpowiedzi podaję adresy IP.
Marcelo Cantos

Domena nie jest zaszyfrowana. Ma to na celu obsługę hostów wirtualnych opartych na nazwach (w porównaniu z adresami IP). @MarceloCantos jest całkowicie poprawne, że reszta adresu URL (tj. GETPolecenie) jest zaszyfrowana. Jest to omówione w RFC 4366
hafichuk

@hafichuk: Dzięki za to. Nie zdawałem sobie sprawy, że TLS może reklamować fqdn. Ostatnim razem, gdy próbowałem skonfigurować multiserwer https (kilka lat temu, przyznaję), wydawało się to niemożliwe na jednym IP.
Marcelo Cantos

Naprawdę ważny dodatek do TLS zawierającego nazwę domeny: Nie zapomnij o żądaniu DNS w postaci zwykłego tekstu, które zawiera również nazwę domeny. Jest szansa, że ​​ktoś, kto może zobaczyć Twój zaszyfrowany ruch HTTPS, może również obserwować Twoje żądania DNS.
Tim G

63

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.


2
+1 dzięki. Znajduje się na moim własnym serwerze fizycznym, więc nie martwię się zbytnio o logi, ale to dobra uwaga dla każdego, kto rozważa to we współdzielonym środowisku hostingu. Warto też wziąć to pod uwagę, ponieważ będę przenosić numery kart kredytowych w ten sposób i na pewno nie będę ich rejestrować :)
orokusaki

3
Nie ma znaczenia, że ​​to twoje własne pudełko. Nie chcesz, aby ktokolwiek inny, kto jest jego właścicielem (tj. Źli hakerzy), również widział te hasła w postaci zwykłego tekstu. Albo te numery CC (zakładając, że nie przechowujesz ich również gdzie indziej).
Thomas,

1
Powinieneś umieścić je w treści POST, a nie w ciągu zapytania URL.
Thomas

1
Czy obawiasz się, że wbeserver ma mniejsze ograniczenia w dostępie do swoich logów niż w dostępie do danych witryny (bazy danych, pliku itp.)? IMHO, o ile dane bezpiecznie uzyskują dostęp do serwera internetowego, wszystko jest w porządku. jedyne osoby, które mają dostęp do serwera internetowego, należy uznać za wiarygodne, ponieważ jeśli nie, nie ma możliwości, aby uniemożliwić im odczytanie danych w taki czy inny sposób.
Serge Profafilecebook

1
Gdy hasła są wysyłane przez GET i są rejestrowane w dzienniku dostępu, NIE są szyfrowane. Uważam, że to największy problem. Zaszyfrowanie haseł w bazie danych nie ma znaczenia, czy można je po prostu wyszukać w dzienniku dostępu serwera WWW. Powinny być zaszyfrowane w bazie danych, jeśli nie, popraw to.
Steen Schütt

21

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



6

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


1
które serwery? dostępne dla kogo?
Jader Dias

2
@Jader przynajmniej do administratorów tych serwerów i hakerów. W przypadku żądania POST informacje nie pozostają w dziennikach, więc jeśli nie zostaną jawnie zarejestrowane, nie ma problemu z dziennikami. Zapytania GET pozostają w dziennikach i jeśli cokolwiek stanie się z dziennikiem (lub administrator zdecyduje się użyć tych dzienników do jakichkolwiek złych działań), masz kłopoty.
Eugene Mayevski 'Callback

4

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


4

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.


4

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!


3

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.


1
Pojawia się HTTP/1.1na końcu pierwszej linii.
Marcelo Cantos

@Marcelos Cantos: Dzięki, minęło trochę czasu, odkąd musiałem ręcznie pisać żądania HTTP.
Morfildur

0

Żą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.


JFYI: istnieje rozszerzenie TLS, które umożliwia klientowi określenie nazwy hosta, dzięki czemu serwer może wybrać odpowiedni certyfikat.
Eugene Mayevski 'Callback'

@Eugene: Dzięki - jestem świadomy rozszerzenia TLS, ale tylko w najszerszym sensie świadomości - nie wiem nic o szczegółach ani o tym, jak szeroko może (lub nie) być w rzeczywistym użyciu.
Michael Burr,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.