On 11/12/17 14:06, G~D~Lunatic wrote:
my squid is a transparent proxy.
You have an interception proxy. It is modifying the TCP/IP packets with
NAT and the TLS handshakes with SSL-Bump stare+bump.
<https://tools.ietf.org/html/rfc3040#section-2.1>
<https://tools.ietf.org/html/rfc3040#section-2.5>
To be properly a "transparent proxy" requires use of TPROXY interception
on the http_port and peek+splice on the ssl_bump.
when i use WeChat client upload file or picture, it failed.
Please explain "it failed".
What does the client receive ?
What is received when it does not fail ?
Please also be aware that securely written App's use "certificate
pinning" or similar mechanisms to ensure their traffic is not
intercepted / bump'ed. There is nothing Squid can do about those - they
*will* fail if bumping is attempted.
the access.log shows that
1512953345.798 75 192.168.51.15 TAG_NONE/200 0 CONNECT
111.206.23.97:443 - ORIGINAL_DST/111.206.23.97 -
The above is a TCP connection reaching SSL-Bump step2 bump'ing. No TLS
SNI was provided by the client.
1512953345.805 0 192.168.51.15 TAG_NONE/503 4380 POST
https://msg.71.am/v5/ypt/hcdn_multicurl - HIER_NONE/- text/html
The above looks like Squid delivering an error about something going
wrong in the TLS handshake. IIRC Alex already mentioned to you that
Squid bump's these TLS handshakes with invalid certs to deliver errors
in a way that Browsers will display.
It may or may not be related to the earlier CONNECT line. Details of the
error are found within the encrypted 503 response itself, not logged.
The below are all different TCP connections being stare'd at step1.
1512953349.713 10 192.168.51.15 TAG_NONE/200 0 CONNECT
101.226.152.108:443 - HIER_NONE/- -
1512953350.931 10 192.168.51.15 TAG_NONE/200 0 CONNECT
123.151.76.49:443 - HIER_NONE/- -
1512953354.059 11 192.168.51.15 TAG_NONE/200 0 CONNECT
123.151.76.49:443 - HIER_NONE/- -
i used wireshark catch the package, Encrypted Alert was shown.
i want to know where the problem or how i can do.
The only int of a problem is that 503 being generated by Squid due to
something unknown. No details of what might be causing that are visible
in any of the info you provided.
Here is my configure
https_port 192.168.51.200:3129 intercept ssl-bump connection-auth=off
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
cert=/usr/local/squid/ssl_cert/myCA.pem
key=/usr/local/squid/ssl_cert/myCA.pem options=NO_SSLv3,NO_SSLv2
When cert= and key= are the same file, you do not have to configure the
key= option.
The dynamic_cert_mem_cache_size=4MB is the default value, no need to
configure defaults explicitly like that.
One test to try is removing that options= setting. If the problem goes
away then the client TLS handshake is requiring SSL. Use of that
protocol is bad, but still sometimes unavoidable.
acl broken_sites ssl::server_name matchweb.sports.qq.com
acl ssl_step1 at_step SslBump1
acl ssl_step2 at_step SslBump2
acl ssl_step3 at_step SslBump3
ssl_bump splice broken_sites
#ssl_bump splice all
ssl_bump stare ssl_step1
ssl_bump bump ssl_step2
ssl_bump terminate ssl_step3
The absence of a stare at step2 prohibits the ability of Squid to mimic
server details in the TLS handshake it delivers to the client. Without
mimic the chances of TLS failure get *much* greater.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
