Чаму Squid запісвае хост HTTPS, а не шлях старонкі
Тлумачыць адсутнасць шляхоў HTTPS у звычайных журналах Squid CONNECT, не ўспрымаючы перахоп TLS як звычайную наладку журнала.
Запіс для shop.example:443 не дае Squid шлях /orders/42. CONNECT запытвае хост/порт; затым TLS прызначэння нясе шлях HTTP унутры тунеля.
| Доказ | Звычайная перадача CONNECT |
|---|---|
| Мэтавы хост/порт і вынік тунеля | Даступна проксі. |
| Унутраны шлях HTTPS і запыт праграмы | Зашыфравана паміж кліентам і сайтам. |
Фрагмент URL браўзера, які пачынаецца з # | Звычайна застаецца ў кліенце, нават па-за журналам проксі. |
Фармат журнала можа запісваць палі, якія мае Squid, але не расшыфроўвае незаўважаныя паведамленні. Звычайная перадача HTTP іншая, бо пасярэднік атрымлівае гэты запыт HTTP. Больш падрабязны вывад не змяняе мяжу CONNECT.
Кіраваны перахоп TLS змяняе давер кліента і адміністрацыйныя патрабаванні. Гэта не маленькі пераключальнік журнала і не патрэбна для звычайнага прама-проксі, які змяняе IP.
Калі праграма ваша і патрэбна дыягностыка на ўзроўні старонкі, выкарыстоўвайце яе журналы або належным чынам распрацаваную тэлеметрыю кліента. Для збояў проксі захоўвайце мэтавы хост, час, статус і завершаны этап злучэння; яны часта вызначаюць праблему без збору прыватных шляхоў старонак.