Modul de a face acest lucru este să utilizați caracteristica ssl peek introdusă în Squid 3.5. Vedea Aici pentru o explicație detaliată. Rețineți că va trebui să fi compilat cu oricare --cu-gnutls sau --cu-openssl (Verifica calmar -v). Unele distribuții le opresc.
Pe scurt, configurația de calmar relevantă arată astfel.
acl denylist_ssl ssl::server_name google.com # NU dstdomain
acl step1 at_step SslBump1
ssl_bump peek pasul 1
ssl_bump splice !denylist_ssl # permiteți tot ce nu este în denylist
ssl_bump termina totul # blochează orice altceva
https_port 3129 intercept ssl-bump cert=/etc/squid/dummy.pem
(Deoparte: nu sunt sigur de ce trebuie să aruncăm o privire doar la pasul 1 și nu la pasul 2, având în vedere că pasul 2 implică doar primirea certificatului de server. Documentele nu explică deloc acest lucru. Utilizarea ssl_bump peek all așa cum recomandă ei, face ca acest lucru să nu mai funcționeze complet).
Și apoi dansează portul obișnuit de redirecționare de la 443 la 3129 folosind iptables (sau pune squid să asculte direct pe 443 dacă preferi).
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3129
Puteți folosi orice certificat pentru manechin, de fapt nu îl folosim niciodată (pentru că nu decriptăm traficul).
Ceva de genul acesta funcționează.
openssl req -new -newkey rsa:4096 -sha256 -days 365 -nodes -x509 -keyout dummy.pem -out dummy.pem
Surse:
[1] https://unix.stackexchange.com/questions/613359/setting-up-squid-transparent-proxy-with-ssl-bumping-on-debian-10
[2] https://web.archive.org/web/20210128152111/https://www.cammckenzie.com/blog/index.php/2018/07/19/squid-https-interception-and-filtering-without-client- certificate/
[3] https://wiki.squid-cache.org/Features/SslPeekAndSplice
