Чи також дані GET зашифровані в HTTPS?


127

Коли ви отримаєте

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

%sЗапит шифрується? Або просто відповідь? Якщо це не так, то чому Google повинен також публікувати контент загальнодоступним разом із шифруванням?

Відповіді:


145

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

Однак зауважте, що пакет «Привіт клієнта рукостискання TLS» може рекламувати повністю кваліфіковане доменне ім’я в простому тексті за допомогою розширення SNI (спасибі @hafichuk), яке використовується всіма сучасними основними браузерами, хоча деякі лише на нових ОС.

EDIT: (Оскільки це щойно отримало мені знак "Good Answer", я думаю, я повинен відповісти на все питання ...)

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

Google обслуговує пошукові запити та інший вміст через https, оскільки не всі вони є загальнодоступними, а також ви можете заховати частину загальнодоступного вмісту з MITM . У будь-якому випадку, краще дозволити Google відповісти самі .


2
Я трохи не задоволений твердженням, що URL-адреса зашифрована. Хіба ім’я хоста не вважалося частиною URL-адреси? Якщо так, твердження неправильне. Неможливо приховати ім'я хоста / IP-адресу від провайдера / проксі-сервера так само, як ви не можете приховати адресу призначення під час надсилання фізичної пошти.
Абхішек Ананд

1
@Abhishek: Ім'я хоста відсутнє в заголовку TCP / IP. Я висвітлюю IP-адреси у своїй відповіді.
Marcelo Cantos

Домен не шифрується. Це для підтримки віртуальних хостів на основі імен (проти IP). @MarceloCantos цілком вірно, що решта URL-адреси (тобто GETкоманди) зашифрована. Це висвітлено у RFC 4366
hafichuk

@hafichuk: Дякую за це. Я не знав, що TLS може рекламувати fqdn. Востаннє, коли я намагався налаштувати https мультисевер (кілька років тому, визнаю), це здалося неможливим протягом одного ip.
Марсело Кантос

Дійсно важливе доповнення до TLS, що містить доменне ім'я: Не забувайте простий DNS-запит простого тексту, включаючи ім'я домену. Можливо, хтось може бачити ваш зашифрований трафік HTTPS, також може переглядати ваші запити DNS.
Тім Г

63

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

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


2
+1 спасибі Це на моєму власному фізичному сервері, тому я не надто переживаю журнали, але це добре враховує тих, хто розглядає це в умовах спільного хостингу. Це також важливо враховувати, тому що я буду переносити номери кредитних карт таким чином, і я точно не захочу їх реєструвати :)
orokusaki

3
Не важливо, що це ваша власна коробка. Ви також не хочете, щоб хто-небудь, хто володіє ним (тобто злі хакери), бачив ці паролі у простому тексті. Або ці номери CC (якщо припустити, що ви їх також не зберігаєте).
Томас

1
Ви повинні помістити їх у тіло POST, а не рядок запиту URL.
Томасе

1
Чи побоюєтесь, що wbeserver має менші обмеження на доступ до своїх журналів, ніж на доступ до даних веб-сайту (БД, файл тощо)? IMHO, поки дані безпечно отримують доступ до веб-сервера, все добре. Єдиним людям, які мають доступ до веб-сервера, слід вважати надійними, тому що якщо їх немає, ви не зможете їм заважати читати дані так чи інакше.
Serge Profafilecebook

1
Коли паролі надсилаються через GET і вони реєструються в журналі доступу, вони НЕ хешируються. Я вважаю, що це найбільше питання. Хеширование паролів у базі даних не має значення, чи можете ви просто шукати їх у журналі доступу веб-сервера. Вони повинні бути хешировані в базі даних, якщо їх немає, виправте це.
Стін Шютт

21

HTTPS Встановлює базове конекцію SSL перед передачею будь-яких даних HTTP. Це гарантує, що всі дані URL-адреси (за винятком імені хоста, яке використовується для встановлення з'єднання), переносяться виключно в рамках цього зашифрованого з'єднання і захищаються від атаки "людина-в-середині" так само, як і будь-які дані HTTPS.

Сказане є частиною ДУЖЕ вичерпної відповіді з відповідей Google, розміщених тут:

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



6

Все зашифровано, але вам потрібно пам’ятати, що ваш запит залишатиметься в журналах сервера та буде доступний різним аналізаторам журналів тощо (що зазвичай не відповідає запиту POST).


1
які сервери? доступні кому?
Jader Dias

2
@Jader хоча б адміністраторам цих серверів і хакерам. З POST-запитом інформація не залишається в журналах, тому, якщо вона не введена явно, немає проблем із журналами. GET-запити залишаються в журналах, і якщо що не трапиться з журналом (або адміністратор вирішить використовувати ці журнали для будь-яких поганих дій), у вас виникнуть проблеми.
Євген Маєвський "Зворотний виклик

4

З'єднання шифрується до передачі запиту. Так, так, запит також шифрується, включаючи рядок запиту.


4

Так, це безпечно. SSL шифрує все.

Витяг із запиту POST:

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

Витяг із запиту GET:

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

В обох випадках все, що надсилається в сокет, шифрується. Те, що клієнт бачить параметри у своєму браузері під час GET-запиту, не означає, що чоловік у середині побачив би те саме.


4

Я просто підключився через HTTPS до веб-сайту і передав купу параметрів GET. Тоді я використовував дротик, щоб нюхати мережу. Використовуючи HTTP, URL надсилається незашифрованим, це означає, що я легко бачу всі параметри GET в URL-адресі. За допомогою HTTPS все зашифровано, і я навіть не можу побачити, який пакет є командою 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, запитуване ім'я хоста не відомо до розшифровки.


1
HTTP/1.1Набирає чинності по закінченні першого рядка.
Марсело Кантос

@Marcelos Cantos: Дякую, минуло час, як мені довелося писати запити HTTP вручну.
Морфілдур

0

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


JFYI: Існує розширення TLS, яке дозволяє клієнту вказати ім'я хоста, і сервер може вибрати відповідний сертифікат.
Євген Маєвський 'Зворотний виклик

@Eugene: Дякую - я знаю про розширення TLS, але лише в самому слабкому розумінні - я нічого не знаю про деталі чи про те, наскільки широко він може (чи не може) бути фактичним використанням.
Майкл Берр
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.