On 9/25/19 1:27 PM, Gaël Ranaivo wrote: > Here is a minimal squid config that demonstrates this weird issue: > > http_port 3128 ssl-bump tls-cert=/tmp/cert.pem tls-key=/tmp/key.pem > > acl regua browser .*Firefox.* > http_access allow regua > http_access deny all > > acl step1 at_step SslBump1 > acl step2 at_step SslBump2 > acl youtube dstdomain .youtube.com > > ssl_bump peek step1 > ssl_bump splice step2 youtube > ssl_bump bump step2 all > > With this config and using Firefox to go to https://youtube.com/, > squid replies to the CONNECT with 2 different replies, causing > an SSL_ERROR_RX_RECORD_TOO_LONG error in the browser: > > HTTP/1.1 200 Connection established > HTTP/1.1 403 Forbidden If the second response is sent in plain text, without waiting for an encrypted request from the browser, then this is a Squid bug. If the second response is sent encrypted, after receiving an encrypted GET (or similar) request from the browser, then this is intended (for now) behavior: SslBump bumps tunnels to report errors to users because browsers refuse to support CONNECT errors properly. > Adding this line: > > http_access allow step2 > > seems to "fix" the problem, but I'm not sure if this is the right thing > to do? Using step2 like that feels dangerous and goes against (possibly excessively conservative) at_step documentation. If you want to allow all CONNECT requests, I would allow all CONNECT requests explicitly instead of (ab)using step2 ACL to do the same. HTH, Alex. > Squid version is 4.6 on debian recompiled with ssl support. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
