> -----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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
