Zakaj Squid zabeleži gostitelja HTTPS, ne pa poti strani
Pojasnjuje manjkajoče poti HTTPS v običajnih dnevnikih Squid CONNECT, ne da bi prestrezanje TLS obravnaval kot rutinsko prilagoditev dnevnika.
Vnos za shop.example:443 Squidu ne da poti /orders/42. CONNECT zahteva gostitelja/vrata; nato TLS cilja nosi pot HTTP znotraj tunela.
| Dokaz | Običajno posredovanje CONNECT |
|---|---|
| Ciljni gostitelj/vrata in izid tunela | Na voljo proxyju. |
| Notranja pot HTTPS in zahteva aplikacije | Šifrirano med odjemalcem in spletnim mestom. |
Del URL-a brskalnika, ki se začne z # | Običajno ostane v odjemalcu, tudi zunaj dnevnika proxyja. |
Format dnevnika lahko zabeleži polja, ki jih ima Squid, ne more pa dešifrirati nevidenih sporočil. Običajno posredovanje HTTP je drugačno, ker posrednik prejme to zahtevo HTTP. Podrobnejši izhod ne spremeni meje CONNECT.
Upravljano prestrezanje TLS spremeni zaupanje odjemalca in upravne zahteve. Ni majhno stikalo za dnevnik in ni potrebno za običajni posredniški proxy, ki menja IP.
Če je aplikacija vaša in potrebujete diagnostiko na ravni strani, uporabite njene dnevnike ali ustrezno zasnovano telemetrijo odjemalca. Pri napakah proxyja shranite ciljnega gostitelja, čas, stanje in zaključeno fazo povezave; ti pogosto najdejo težavo brez zbiranja zasebnih poti strani.