De ce Squid înregistrează gazda HTTPS, dar nu calea paginii
Explică lipsa căilor HTTPS în jurnalele Squid CONNECT obișnuite fără a trata interceptarea TLS ca o ajustare de rutină a jurnalului.
O înregistrare pentru shop.example:443 nu îi dă lui Squid calea /orders/42. CONNECT cere o gazdă/port; apoi TLS destinației duce calea HTTP în interiorul tunelului.
| Dovadă | Retransmitere CONNECT obișnuită |
|---|---|
| Gazda/portul destinației și rezultatul tunelului | Disponibil pentru proxy. |
| Calea HTTPS internă și cererea aplicației | Criptat între client și site. |
Fragmentul de URL al browserului care începe cu # | Rămâne de obicei în client, chiar în afara jurnalului proxy. |
Un format de jurnal poate înregistra câmpurile pe care le are Squid, nu poate decripta mesaje nevăzute. Redirecționarea HTTP simplă este diferită pentru că intermediarul primește acea cerere HTTP. O ieșire mai detaliată nu schimbă granița CONNECT.
Interceptarea TLS administrată schimbă încrederea clientului și cerințele administrative. Nu este un mic comutator de jurnal și este inutilă pentru un proxy de redirecționare normal care schimbă IP-ul.
Dacă aplicația este a dumneavoastră și aveți nevoie de diagnostic la nivel de pagină, folosiți jurnalele ei sau telemetrie de client proiectată corespunzător. Pentru eșecurile proxy, păstrați gazda destinației, momentul, starea și etapa de conexiune finalizată; acestea localizează adesea problema fără a colecta căi de pagină private.