Proč Squid zaznamenává hostitele HTTPS, ale ne cestu stránky
Vysvětluje chybějící cesty HTTPS v běžných protokolech Squid CONNECT, aniž by odposlech TLS považoval za rutinní úpravu logování.
Záznam pro shop.example:443 nedá Squidu cestu /orders/42. CONNECT žádá hostitele/port; poté TLS cíle nese cestu HTTP uvnitř tunelu.
| Důkaz | Běžné předávání CONNECT |
|---|---|
| Cílový hostitel/port a výsledek tunelu | Dostupné proxy. |
| Vnitřní cesta HTTPS a požadavek aplikace | Šifrováno mezi klientem a webem. |
Fragment URL prohlížeče začínající znakem # | Obvykle zůstává v klientovi, i mimo logování proxy. |
Formát protokolu může zaznamenat pole, která Squid má, ne dešifrovat neviděné zprávy. Běžné předávání HTTP je jiné, protože zprostředkovatel dostává tento požadavek HTTP. Podrobnější výstup nemění hranici CONNECT.
Spravovaný odposlech TLS mění důvěru klienta a administrativní požadavky. Není to malý přepínač logování a pro běžnou dopřednou proxy měnící IP není nutný.
Pokud aplikaci vlastníte a potřebujete diagnostiku na úrovni stránky, použijte její protokoly nebo vhodně navrženou telemetrii klienta. U selhání proxy si ponechte cílového hostitele, časování, stav a dokončenou fázi spojení; často lokalizují problém bez sběru soukromých cest stránek.