Чому Squid записує хост HTTPS, але не шлях сторінки
Пояснює відсутність шляхів HTTPS у звичайних журналах Squid CONNECT, не вважаючи перехоплення TLS рутинним налаштуванням журналу.
Запис для shop.example:443 не дає Squid шлях /orders/42. CONNECT запитує хост/порт; далі TLS призначення несе шлях HTTP усередині тунелю.
| Доказ | Звичайна передача CONNECT |
|---|---|
| Цільовий хост/порт і результат тунелю | Доступно проксі. |
| Внутрішній шлях HTTPS і запит застосунку | Зашифровано між клієнтом і сайтом. |
Фрагмент URL браузера, що починається з # | Зазвичай залишається в клієнті, навіть поза журналом проксі. |
Формат журналу може записувати поля, які має Squid, але не розшифровує небачені повідомлення. Звичайна пересилка HTTP інша, бо посередник отримує цей HTTP-запит. Детальніший вивід не змінює межі CONNECT.
Кероване перехоплення TLS змінює довіру клієнта й адміністративні вимоги. Це не маленький перемикач журналу, і він не потрібен звичайному форвардному проксі, що змінює IP.
Якщо застосунок ваш і потрібна діагностика на рівні сторінки, використовуйте його журнали або належно спроєктовану телеметрію клієнта. Для збоїв проксі зберігайте хост призначення, час, статус і завершений етап з'єднання; вони часто знаходять проблему без збору приватних шляхів сторінок.