Bakit nire-record ng Squid ang HTTPS host pero hindi ang path ng pahina
Ipinapaliwanag ang mga nawawalang HTTPS path sa karaniwang Squid CONNECT log nang hindi tinatrato ang TLS interception bilang karaniwang pagsasaayos ng log.
Ang rekord para sa shop.example:443 ay hindi nagbibigay sa Squid ng path na /orders/42. Ang CONNECT ay humihingi ng host/port; pagkatapos ay dinadala ng TLS ng destinasyon ang HTTP path sa loob ng tunnel.
| Ebidensya | Karaniwang CONNECT relay |
|---|---|
| Target host/port at resulta ng tunnel | Magagamit ng proxy. |
| Panloob na HTTPS path at kahilingan ng aplikasyon | Naka-encrypt sa pagitan ng client at website. |
Bahagi ng URL ng browser na nagsisimula sa # | Karaniwang nananatili sa client, kahit labas ng proxy log. |
Format ng log ay makakapagtala ng mga field na mayroon ang Squid, hindi ma-decrypt ang mga hindi nakikitang mensahe. Ang simpleng HTTP forwarding ay iba dahil natatanggap ng intermediary ang HTTP request na iyon. Ang mas detalyadong output ay hindi nagbabago sa hangganan ng CONNECT.
Ang pinamamahalaang TLS interception ay nagbabago ng tiwala ng client at mga administratibong pangangailangan. Hindi ito maliit na logging switch at hindi kailangan para sa normal na forward proxy na nagpapalit ng IP.
Kung pagmamay-ari mo ang aplikasyon at kailangan mo ng page-level diagnostics, gamitin ang mga log nito o telemetry ng client na angkop na dinisenyo. Para sa mga pagpalya ng proxy, itago ang destination host, timing, status at natapos na yugto ng koneksyon; madalas nilang matukoy ang problema nang hindi nangongolekta ng pribadong page path.