Чи зашифровані всі URL-адреси при використанні шифрування TLS / SSL (HTTPS)? Мені хотілося б знати, оскільки я хочу, щоб усі дані URL-адреси були приховані при використанні TLS / SSL (HTTPS).

Якщо TLS / SSL дає вам повне шифрування URL-адрес, мені не доведеться турбуватися про приховування конфіденційної інформації від URL-адрес.

Так, з'єднання SSL знаходиться між шаром TCP та шаром HTTP. Клієнт і сервер спочатку встановлюють захищений зашифрований TCP-з'єднання (через протокол SSL / TLS), а потім клієнт відправить HTTP-запит (GET, POST, DELETE ...) над цим зашифрованим TCP-з'єднанням.

Оскільки ніхто не забезпечив захоплення дротом, ось такий.
Ім'я сервера (доменна частина URL) представлена ​​в ClientHelloпакеті в простому тексті .

Далі показано запит браузера на:
https://i.stack.imgur.com/path/?some=parameters&go=here

Додаткову інформацію див. У полях версій TLS (їх є 3 - не версії, поля, що містять номер версії!)

З https://www.ietf.org/rfc/rfc3546.txt :

3.1. Вказівка ​​імені сервера

[TLS] не забезпечує механізм для клієнта повідомляти серверу ім'я сервера, з яким він контактує. Клієнтам може бути бажано надати цю інформацію для полегшення безпечного з'єднання з серверами, що розміщують декілька "віртуальних" серверів за однією базовою мережевою адресою.

Для того, щоб вказати ім’я сервера, клієнти МОЖУТЬ включити розширення типу "ім'я_сервера" у (розширений) привіт клієнта.

Коротко:

• FQDN (частина домену URL-адреси) МОЖЕ бути передано чітко всередині ClientHelloпакета, якщо використовується розширення SNI

• У решті URL-адреси ( /path/?some=parameters&go=here) немає жодної справи, ClientHelloоскільки URL-адреса запиту - це HTTP (OSI Layer 7), тому він ніколи не відображатиметься в рукостисканні TLS (4 або 5 рівня). Це з’явиться пізніше у GET /path/?some=parameters&go=here HTTP/1.1запиті HTTP, ПІСЛЯ встановлений захищений TLS канал.

РЕЗЮМЕ

Ім’я домену МОЖЕ бути передано чітко (якщо розширення SNI використовується в рукостисканні TLS), але URL-адреса (шлях та параметри) завжди шифрується.

ОНОВЛЕННЯ БЕРЕЗЕНЯ 2019 року

Дякуємо carlin.scott за те, що підняв цей.

Корисне навантаження в розширенні SNI тепер може бути зашифровано за допомогою цього проекту пропозиції RFC . Ця можливість існує лише в TLS 1.3 (як опція, і реалізувати її до обох кінців), і немає зворотної сумісності з TLS 1.2 і нижче.

CloudFlare це робить, і ви можете прочитати більше про внутрішні тут - Якщо курка повинна прийти перед яйцем, куди ви кладете курку?

На практиці це означає, що замість того, щоб передавати FQDN у простому тексті (як показує захоплення Wireshark), він тепер шифрується.

ПРИМІТКА. Це стосується аспекту конфіденційності більше, ніж захисного, оскільки зворотний пошук DNS МОЖЕ виявити призначений хост призначення в будь-якому випадку.

Як уже вказали інші відповіді , https "URL-адреси" дійсно зашифровані. Однак, ваш запит / відповідь DNS при вирішенні доменного імені, ймовірно, не відповідає, і, звичайно, якщо ви використовували браузер, ваші URL-адреси можуть також бути записані.

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

Зауважте, що при використанні проксі-сервера HTTP він знає адресу (домен) цільового сервера, але не знає запитуваний шлях на цьому сервері (тобто запит і відповідь завжди шифруються).

Я згоден з попередніми відповідями:

Щоб бути явним:

З TLS перша частина URL-адреси ( https://www.example.com/ ) все ще помітна під час створення з'єднання. Друга частина (/ herearemygetparameters / 1/2/3/4) захищена TLS.

Однак є ряд причин, чому ви не повинні ставити параметри в GET-запиті.

По-перше, як уже згадували інші: - витік через адресний рядок браузера - витік через історію

На додаток до цього у вас є витік URL-адреси через http-реферера: користувач бачить сайт A на TLS, потім натискає посилання на сайт B. Якщо обидва сайти є на TLS, запит на сайт B міститиме повну URL-адресу з сайту A у параметр referer запиту. І адміністратор із сайту B може отримати його з файлів журналу сервера B.)

Доповнення до корисної відповіді Марка Новаковського - URL зберігається у журналах на сервері (наприклад, у / etc / httpd / logs / ssl_access_log), тому якщо ви не хочете, щоб сервер довше зберігав інформацію термін, не вкладайте його в URL-адресу.

Так і ні.

Частина адреси сервера НЕ шифрується, оскільки використовується для налаштування з'єднання.

Це може змінитися в майбутньому із зашифрованими SNI та DNS, але станом на 2018 рік обидві технології часто не використовуються.

Шлях, рядок запиту тощо шифруються.

Примітка для GET-запитів користувач все одно зможе вирізати та вставити URL-адресу з панелі розташування, і ви, ймовірно, не захочете туди вносити конфіденційну інформацію, яку може побачити кожен, хто дивиться на екран.

Сторона, яка відстежує трафік, також може визначити відвідувану сторінку, вивчивши ваш трафік і порівнявши його з трафіком, який має інший користувач під час відвідування сайту. Наприклад, якщо на сайті було лише 2 сторінки, одна значно більша за іншу, то порівняння розміру передачі даних дозволить визначити, яку сторінку ви відвідали. Існують способи, як це можна приховати від сторонніх, але вони не є нормальною поведінкою сервера чи браузера. Дивіться, наприклад, цей документ від SciRate, https://scirate.com/arxiv/1403.0297 .

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

Ви не завжди можете розраховувати на конфіденційність повної URL-адреси. Наприклад, як це буває в корпоративних мережах, пристрої, що постачаються на зразок ПК вашої компанії, налаштовані додатковим кореневим сертифікатом, щоб ваш веб-переглядач міг сподіватися проксі-сервера (перевірити посередницький рівень) трафіку https. . Це означає, що повна URL-адреса піддається огляду. Зазвичай це зберігається в журналі.

Крім того, ваші паролі також піддаються впливу та, ймовірно, реєструються, і це ще одна причина використовувати одноразові паролі або часто змінювати ваші паролі.

Нарешті, вміст запиту та відповіді також відкривається, якщо не зашифровано іншим чином.

Один приклад налаштування інспекції описаний Checkpoint тут . Старий стиль "Інтернет-кафе", використовуючи комп'ютери, що постачаються в комплекті, також може бути створений таким чином.

Посилання на мою відповідь на повторне запитання . URL-адреса доступна не лише в історії веб-переглядачів, а на сервері записує журнали, але також надсилається як заголовок HTTP Referer, який, якщо ви використовуєте сторонній вміст, відкриває URL-адресу джерелам, які не є вашими.

Зараз 2019 рік і TLS v1.3 був випущений. На думку Cloudflare, SNI може бути зашифрований завдяки TLS v1.3. Отже, я сказав собі чудово! давайте подивимося, як це виглядає в пакетах TCP cloudflare.com Отже, я зловив пакет рукостискань "привіт з клієнтом" у відповідь сервера хмарних хвиль, використовуючи Google Chrome як браузер і wireshark як сніффер пакетів. Я все ще можу прочитати ім'я сервера простим текстом у привітному пакеті Клієнта.

Тож остерігайтеся того, що ви можете прочитати, оскільки це все ще не анонімний зв’язок. Проміжне програмне забезпечення між клієнтом і сервером може реєструвати кожен домен, який вимагає клієнт.

Отже, схоже, що для шифрування SNI потрібні додаткові реалізації, щоб працювати разом з TLSv1.3

Наступна стаття описує шифрування SNI, надане Cloudflare як частину TLSv1.3. Однак усі URL-адреси HTTP з cloudflare.com містяться у простому тексті в пакеті TCP під TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/ вызвали3]

Так і ні.

Фактична URL-адреса зашифрована, це означає, що хтось не міг сказати точну веб-сторінку на веб-сайті, який ви відвідали. Однак заголовок TLS включає ім'я хоста сервера, до якого ви звертаєтесь (наприклад, www.quora.com) незашифрованим. DNS також майже ніколи не шифрується, а також просочує ім'я хоста, до якого ви отримуєте доступ. Цей запит DNS майже завжди проти серверів вашого провайдера за замовчуванням, тому вони можуть легко бачити ім'я хосту кожного веб-сайту, до якого ви звертаєтесь, або нюхаючи ваші запити DNS на інші сервери DNS, або записуючи ваші проти власних.

Однак, якщо вас турбує, чи може хтось дізнатися, на якому веб-сайті ви отримували доступ, цього недостатньо. HTTPS працює на OSI Layer 4 і шифрує всі дані на цьому рівні, але нижчі рівні залишаються в мережах, які їх переносять. Хтось все ще може просто простежити шлях та місце призначення трафіку на рівні OSI 3. Це означає, що хтось нюхаючи ваш трафік, може знайти IP-адресу та розширити доменне ім’я веб-сайту, на якому ви отримували доступ.

Гірше, що в перший раз (і в наступні рази, залежно від того, як / коли буде очищено кеш-пам'ять DNS), ви, ймовірно, надішлете незашифрований DNS-запит на будь-який ваш DNS-сервер, щоб запитати IP-адресу вашої цільової URL-адреси HTTPS (знову ж таки, автор за замовчуванням зазвичай сервери вашого провайдера) Кожен, хто має доступ до вашого трафіку по шляху до вашого DNS-сервера, може мати можливість нюхати цей запит.

Якщо ви шукаєте високий рівень конфіденційності, вам потрібно буде доповнити HTTPS довіреною зашифрованою VPN та / або зашифрованою проксі-службою. Ви також можете заглянути в DNSSEC, щоб захистити свої запити DNS. Цей сервіс повинен бути надійним, оскільки вони можуть легко виконати вищенаведене відстеження джерел та напрямків вашого трафіку.

Напевно, тут є кілька хороших відповідей, більшість з яких зосереджується на навігації в браузері. Я пишу це у 2018 році, і, напевно, хтось хоче знати про безпеку мобільних додатків.

Якщо ви керуєте обома кінцями програми (сервер та додаток) для мобільних додатків , якщо ви використовуєте HTTPS, ви захищені . iOS або Android перевірять сертифікат і пом'якшують можливі атаки на MiM (це буде єдиною слабкою стороною у всьому цьому). Ви можете надсилати конфіденційні дані через HTTPS-з'єднання, які будуть зашифровані під час транспортування . Просто ваш додаток і сервер будуть знати будь-які параметри, надіслані через https.

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

Крім того, якщо ви створюєте API ReSTful, проблеми з витоком веб-переглядача та http-реферером в основному пом'якшуються, оскільки клієнт може не бути веб-переглядачем, і у вас може не бути людей, що натискають посилання.

У такому випадку я рекомендую увійти в oAuth2, щоб отримати маркер носія. У такому випадку єдиними конфіденційними даними будуть початкові облікові дані ..., які, ймовірно, повинні бути у запиті після публікації

Хоча у вас вже є дуже хороші відповіді, мені дуже подобається пояснення на цьому веб-сайті: https://https.cio.gov/faq/#what-information-does-https-protect

коротше: використання HTTPS шкур:

• HTTP-метод
• запити парами
• Тіло POST (якщо воно є)
• Запросити заголовки (файли cookie)
• Код статусу