Per què els navegadors poden amagar la pàgina de bloqueig HTTPS de Squid
Enteneu per què un navegador pot mostrar el seu propi error de túnel en lloc de l'HTML personalitzat retornat per a una sol·licitud CONNECT denegada.
La pàgina de bloqueig personalitzada del proxy apareix per a un lloc HTTP. Per a un lloc HTTPS, el navegador mostra en canvi un error de túnel. Tornar a substituir la plantilla HTML pot no canviar res.
Amb un proxy HTTP explícit, una visita HTTPS sol començar amb CONNECT. El navegador demana al proxy que obri un túnel cap a un amfitrió i un port. Si Squid rebutja aquesta sol·licitud, la sessió TLS del lloc no s'inicia mai.
El rebuig pot tenir un estat HTTP i contingut de resposta. Podeu inspeccionar aquesta resposta CONNECT fallida amb curl independentment de la pàgina d'error del navegador. Això no requereix que el navegador presenti l'HTML subministrat com la pàgina web de la destinació. Un navegador pot descartar el cos de l'error CONNECT i utilitzar la seva pròpia interfície d'error de proxy; la presentació exacta depèn del client.
Si el rebuig de Squid ja conté el cos deny_info previst, editar-ne el text, el full d'estil o els permisos del fitxer no canvia quina etapa de la resposta gestiona el navegador. Mantingueu disponibles l'estat del rebuig i el registre d'accés per establir si CONNECT es va denegar i per què. Una pàgina genèrica del navegador pot amagar detalls de la política mentre el proxy aplica correctament la regla.
Servir una pàgina de bloqueig dins d'una connexió HTTPS interceptada és una altra arquitectura, que implica terminació TLS, confiança del client i gestió de certificats. No s'habilita editant deny_info, i una plantilla personalitzada no atorga cap autoritat per suplantar el lloc bloquejat. Trieu aquest disseny només si cal; en cas contrari, utilitzeu la informació d'errors disponible del client i els registres operatius del proxy.