Данные GET также зашифрованы в HTTPS?

129

Когда вы получаете

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

%sЗашифрован ли запрос? Или просто ответ? Если это не так, почему Google должен предоставлять свой общедоступный контент также с использованием шифрования?

https http-get

— Джадер Диас
источник

148

Весь запрос зашифрован, включая URL-адрес и даже команду ( GET). Единственное, что может узнать вмешивающаяся сторона, такая как прокси-сервер, - это адрес и порт назначения.

Однако обратите внимание, что пакет Client Hello подтверждения TLS может рекламировать полное доменное имя в виде открытого текста через расширение SNI (спасибо @hafichuk), которое используется всеми современными основными браузерами, хотя некоторые только в новых ОС.

РЕДАКТИРОВАТЬ: (Поскольку это только что принесло мне значок «Хороший ответ», я думаю, я должен ответить на весь вопрос…)

Весь ответ также зашифрован; прокси не могут перехватить какую-либо его часть.

Google обслуживает поисковые запросы и другой контент через https, потому что не весь он является общедоступным, и вы также можете скрыть часть общедоступного контента от MITM . В любом случае лучше позволить Google ответить за себя .

— Марсело Кантос
источник

2

Я немного недоволен утверждением, что URL-адрес зашифрован. Разве имя хоста не считается частью URL-адреса? Если так, то утверждение неверно. Невозможно скрыть имя хоста / IP-адрес от ISP / прокси-сервера так же, как вы не можете скрыть адрес назначения при отправке физической почты.

— Abhishek Anand

1

@Abhishek: имя хоста отсутствует в заголовке TCP / IP. В своем ответе я указываю IP-адреса.

— Марсело Кантос

Домен не зашифрован. Это сделано для поддержки виртуальных хостов на основе имен (а не на основе IP). @MarceloCantos совершенно правильно, что остальная часть URL (т.е. GETкоманда) зашифрована. Это

— описано

@hafichuk: Спасибо за это. Я не понимал, что TLS может рекламировать fqdn. В последний раз, когда я пытался настроить мультисервер https (признаюсь, несколько лет назад), это казалось невозможным для одного IP.

— Marcelo Cantos

Действительно важное дополнение к TLS, содержащему доменное имя: не забывайте, что DNS-запрос в виде открытого текста также включает доменное имя. Скорее всего, кто-то, кто видит ваш зашифрованный HTTPS-трафик, также может отслеживать ваши DNS-запросы.

— Tim G

65

Сам URL-адрес зашифрован, поэтому параметры в строке запроса не передаются по сети.

Однако имейте в виду, что URL-адреса, включающие данные GET, часто регистрируются веб-сервером, тогда как данные POST - редко. Так что, если вы планируете сделать что-то подобное /login/?username=john&password=doe, не делайте этого; вместо этого используйте POST.

— Томас
источник

2

+1 спасибо. Это на моем собственном физическом сервере, поэтому я не слишком беспокоюсь о журналах, но это хорошее соображение для всех, кто рассматривает это в среде общего хостинга. Это также важно учитывать, потому что я буду передавать номера кредитных карт таким образом и определенно не захочу их регистрировать :)

— orokusaki

3

Неважно, что это твоя собственная коробка. Вы также не хотите, чтобы кто-либо другой, кто владеет им (например, злые хакеры), видел эти пароли в виде обычного текста. Или эти номера CC (при условии, что вы не храните их в другом месте).

— Thomas

1

Вы должны поместить их в тело POST, а не в строку запроса URL.

— Thomas

1

Вы опасаетесь, что wbeserver имеет меньше ограничений на доступ к своим журналам, чем на доступ к данным веб-сайта (БД, файлу и т. Д.)? ИМХО, пока данные получают безопасный доступ к веб-серверу, все в порядке. единственные люди, у которых есть доступ к веб-серверу, должны считаться надежными, потому что в противном случае вы не сможете помешать им прочитать данные тем или иным образом.

— Serge Profafilecebook

1

Когда пароли отправляются через GET и регистрируются в журнале доступа, они НЕ хешируются. Я считаю, что это самая большая проблема. Наличие хешированных паролей в базе данных не имеет значения, если вы можете просто найти их в журнале доступа веб-сервера. Они должны быть хешированы в базе данных, если нет, исправьте это.

— Steen Schütt

22

HTTPS Устанавливает базовое соединение SSL перед передачей любых данных HTTP. Это гарантирует, что все данные URL (за исключением имени хоста, которое используется для установления соединения) передаются исключительно в этом зашифрованном соединении и защищены от атак типа «злоумышленник в середине» так же, как и любые данные HTTPS.

Вышесказанное является частью ОЧЕНЬ исчерпывающего ответа от Google Answers, расположенных здесь:

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

— DVK
источник

18

Часть URL-адреса после имени хоста отправляется безопасно.

Например, https://somewhere.com/index.php?NAME=FIELD.

/index.php?NAME=FIELDЧасть шифруется. Это somewhere.comне так.

— levis501
источник

7

Все зашифровано, но вы должны помнить, что ваш запрос останется в журналах сервера и будет доступен для различных анализаторов журналов и т. Д. (Что обычно не относится к запросу POST).

— Обратный звонок Евгения Маевского
источник

1

какие сервера? доступно кому?

— Jader Dias

2

@Jader как минимум админам тех серверов и хакерам. С запросом POST информация не остается в журналах, поэтому, если он не зарегистрирован явно, с журналами нет проблем. Запросы GET остаются в журналах, и если что-то случится с журналом (или администратор решит использовать эти журналы для любых плохих действий), у вас проблемы.

— Обратный звонок Евгения Маевского

5

Перед отправкой запроса соединение шифруется. Так что да, запрос тоже зашифрован, включая строку запроса.

— Chao
источник

5

Я только что подключился через HTTPS к веб-сайту и передал кучу параметров GET. Затем я использовал wirehark для обнюхивания сети. При использовании HTTP URL-адрес отправляется в незашифрованном виде, что означает, что я могу легко увидеть все параметры GET в URL-адресе. Используя HTTPS, все зашифровано, и я даже не могу увидеть, какой пакет является командой GET, не говоря уже о его содержимом!

— Джефф Лэмб
источник

4

Да, это безопасно. SSL шифрует все.

Выдержка из запроса POST:

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

Выдержка из GET-запроса:

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

В обоих случаях все, что отправляется через сокет, зашифровывается. Тот факт, что клиент видит параметры в своем браузере во время запроса GET, не означает, что человек посередине увидит то же самое.

— Дарин Димитров
источник

3

SSL выполняется перед синтаксическим анализом заголовка, это означает:

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

Запрос выглядит примерно так (не могу вспомнить точный синтаксис, но это должно быть достаточно близко):

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

По этой же причине наличие разных SSL-сертификатов для нескольких хостов на одном IP-адресе проблематично, запрошенное имя хоста неизвестно до расшифровки.

— Morfildur
источник

1

В HTTP/1.1конце первой строки.

— Марсело Кантос

@Marcelos Cantos: Спасибо, давно мне не приходилось писать HTTP-запросы вручную.

— Морфилдур

0

Запрос GET зашифрован при использовании HTTPS - на самом деле, именно поэтому защищенные веб-сайты должны иметь уникальный IP-адрес - нет способа получить предполагаемое имя хоста (или виртуальный каталог) из запроса до тех пор, пока он не будет расшифрован.

— Майкл Берр
источник

JFYI: существует расширение TLS, которое позволяет клиенту указывать имя хоста, и поэтому сервер может выбрать соответствующий сертификат.

— Обратный звонок Евгения Маевского

@Eugene: Спасибо - я знаю о расширении TLS, но только в самом слабом смысле - я ничего не знаю ни о деталях, ни о том, насколько широко оно может (или не может) использоваться.

— Майкл Берр,