[squid-users] Squid sends 2 replies after peek/splice when using an user-agent http_access rule

[Alex Rousskov]

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.