Prečo Squid zaznamenáva hostiteľa HTTPS, ale nie cestu stránky
Vysvetľuje chýbajúce cesty HTTPS v bežných protokoloch Squid CONNECT bez toho, aby sa odpočúvanie TLS považovalo za rutinnú úpravu protokolovania.
Záznam pre shop.example:443 nedá Squidu cestu /orders/42. CONNECT žiada hostiteľa/port; potom TLS cieľa nesie cestu HTTP vnútri tunela.
| Dôkaz | Bežné preposielanie CONNECT |
|---|---|
| Cieľový hostiteľ/port a výsledok tunela | Dostupné pre proxy. |
| Vnútorná cesta HTTPS a požiadavka aplikácie | Šifrované medzi klientom a webom. |
Fragment URL prehliadača začínajúci znakom # | Zvyčajne zostáva v klientovi, aj mimo protokolovania proxy. |
Formát protokolu môže zaznamenať polia, ktoré Squid má, nie dešifrovať nevidené správy. Bežné preposielanie HTTP je iné, pretože sprostredkovateľ prijíma tú požiadavku HTTP. Podrobnejší výstup nemení hranicu CONNECT.
Spravované odpočúvanie TLS mení dôveru klienta a administratívne požiadavky. Nie je to malý prepínač protokolovania a pre bežnú doprednú proxy meniacu IP nie je potrebné.
Ak aplikáciu vlastníte a potrebujete diagnostiku na úrovni stránky, použite jej protokoly alebo vhodne navrhnutú telemetriu klienta. Pri zlyhaniach proxy si ponechajte cieľového hostiteľa, časovanie, stav a dokončenú fázu spojenia; často lokalizujú problém bez zhromažďovania súkromných ciest stránok.