[squid-users] squid-users Digest, Vol 56, Issue 12

[Amos Jeffries]

> -----Message d'origine-----
...
>
> When replying, please edit your Subject line so it is more specific
than "Re: Contents of squid-users digest..."

When you are trying to message the list about issues please change your
subscription settings to deliver you the individual posts so you can
reply to threads instead of digests.


On 19/04/19 1:34 am, Wegner Michaël wrote:
> Hi,
> 
> The SSL is OK I always can't play some YouTube video.
> Squid in version 4.6
> In access.log : TCP_TUNNEL/200 2083 CONNECT www.youtube.com:443 - HIER_DIRECT/216.58.206.238
> I think the problem comes from heading.
> 

What are you calling "heading"?


The (incomplete) access.log entry you show has;

 * an unknown client requesting a tunnel to www.youtube.com.

 * Squid is opening a tunnel to the server 216.58.206.238.

 * Squid is informing the client that it was 200/success. The tunnel can
be used.

 * 2083 bytes are sent to the client. Some of those were for the 200
response.

 * the tunnel is closed without any errors having occured.


This line means multiple different things depending on which port your
proxy received it on (if received) or whether Squid generated the
CONNECT pieces for SSL-Bump internal use.


> My squid.conf for test is :
> visible_hostname squid
> 
> acl localnet src 10.0.0.0/8
> 
> acl SSL_ports port 443
> 
> acl Safe_ports port 80          # http
> acl Safe_ports port 21          # ftp
> acl Safe_ports port 443         # https
> acl Safe_ports port 70          # gopher
> acl Safe_ports port 210         # wais
> acl Safe_ports port 1025-65535  # unregistered ports
> acl Safe_ports port 280         # http-mgmt
> acl Safe_ports port 488         # gss-http
> acl Safe_ports port 591         # filemaker
> acl Safe_ports port 777         # multiling http
> 
> acl CONNECT method CONNECT
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localnet
> http_access allow localhost
> http_access deny all
> 
> http_port 3128

Traffic arriving on above port never has SSL-Bump applied to it. Tunnels
are always directly client<->origin with no Squid interaction to the
HTTPS portion.


> https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/ssl_cert/myCA.pem
> 
> ssl_bump splice localhost

Traffic NAT intercepted from localhost is always spliced. The TLS and
wrapped HTTPS are always directly client<->origin with no Squid interaction.

> acl 9 at_step SslBump1
> acl 10 at_step SslBump2
> acl 11 at_step SslBump3
> ssl_bump peek 9 all
> ssl_bump bump 10 all

All traffic which is from non-localhost is always bumped at step-2 by
SSL-Bump.

Step-2 has zero details about the actual origin server TLS capabilities
or properties. Bumping at this step is what we call "client-first". It
has *many* problems and should be avoided unless absolutely necessary.


YouTube is a Google domain. Google are particularly strict about their
TLS usage and security. They do a lot of things to absolutely prohibit
things like client-first being possible at all.

Bump not being possible at all is the normal state for Google domains.
It is more surprising that you are reporting "works fine" for parts of
YT than the failure.

More details will be needed to see what is going on. Please start by
providing the whole of that access.log line and the other log entries
from your test transaction. If bumping is happening at all there *will*
be multiple log entries.


> ssl_bump bump 11 all
> 

Above should never happen because everything was already spliced at
step-1 or bumped at step-2.


Amos