On 11/29/22 08:06, Gabriel Vilariño wrote:
However, in this context, what means TCP_TUNNEL/500? is it because the
TLS handshake? I would like to know if it is tunneling correctly or is
having some trouble (not easy to test right now).
Squid bugs notwithstanding, TCP_TUNNEL/500 means that Squid refused to
tunnel the corresponding TCP connection and responded with an HTTP 500
error to the corresponding HTTP CONNECT request. That client request is
faked in your TLS interception case, so the response is also a fake --
Squid does not really send it to the client.
In most SslBump cases, if Squid cannot successfully peek-and-splice,
then it will try to bump the client connection and, if the client then
sends a GET request on the bumped client-Squid connection, Squid will
respond with a real HTTP 500 error.
AFAICT, the logs you have shared do not detail the TLS error that
triggers that TCP_TUNNEL/500 outcome.
HTH,
Alex.
Thanks!
El mar, 29 nov 2022 a las 13:16, Gabriel Vilariño (<gvilarino6@xxxxxxxxx
<mailto:gvilarino6@xxxxxxxxx>>) escribió:
Hi there,
I am setting up an HTTP/HTTPS transparent proxy, meaning the clients
not need any certificates for using the proxy. This works fine on
version 3.5 of Squid, however after upgrading to 5.7 the behavior of
the logs change:
1669723133.174 8037 10.184.19.220 TCP_TUNNEL/500 6207 CONNECT
54.240.253.128:443 <http://54.240.253.128:443> -
ORIGINAL_DST/54.240.253.128 <http://54.240.253.128> -
Directive: logformat squid %ts.%03tu %>a %Ss/%03>Hs %ssl::>sni
%ssl::bump_mode ssl::>cert_subject %<ru
On version 3.5 we were obtaining the domain name (an aws service) in
the place of ORIGINAL_DST. Also now we are not seeing any
information about the bump_mode in no one of the connections while
before we were seeing it. One could trough that it could be because
of the /500 message, however on a 200 one to docs.ansble.com
<http://docs.ansble.com> it also don´t show any data on the sni field:
1669723513.363 332 10.184.19.220 TCP_TUNNEL/200 38192 CONNECT
104.26.0.234:443 <http://104.26.0.234:443> -
ORIGINAL_DST/104.26.0.234 <http://104.26.0.234> -
Also the 500 looks to come from the squid not understanding
something on the SSL negotiation:
|2022/11/29 10:32:38.943 kid1| 83,4| support.cc(248) check_domain:
Verifying server domain arsenal.us-west-2.amazonaws.com
<http://arsenal.us-west-2.amazonaws.com> to certificate
name/subjectAltName arsenal.us-west-2.amazonaws.com
<http://arsenal.us-west-2.amazonaws.com> ||2022/11/29 10:32:38.943
kid1| 83,5| bio.cc(136) read: FD 28 read 347 <= 65535 ||2022/11/29
10:32:38.943 kid1| 83,5| Io.cc(91) Handshake: -1/0 for TLS
connection 0x558453168970 over conn99 local=SQUID-INTERNAL-IP:44264
remote=54.240.251.223:443 <http://54.240.251.223:443> ORIGINAL_DST
FD 28 flags=1 ||2022/11/29 10:32:38.943 kid1| 83,2|
PeerConnector.cc(256) handleNegotiationResult: ERROR: failure while
establishing TLS connection on FD: 280x558452b68980*1 ||2022/11/29
10:32:38.943 kid1| 83,5| NegotiationHistory.cc(85)
retrieveNegotiatedInfo: SSL connection info on FD 28 SSL version
NONE/0.0 negotiated cipher ||2022/11/29 10:32:38.943 kid1| 83,5|
PeekingPeerConnector.cc(84) checkForPeekAndSpliceMatched: Will check
for peek and splice on FD 28 ||2022/11/29 10:32:38.943 kid1| 83,5|
PeekingPeerConnector.cc(395) serverCertificateVerified: HTTPS server
CN: arsenal.us-west-2.amazonaws.com
<http://arsenal.us-west-2.amazonaws.com> bumped: conn99
local=SQUID-INTERNAL-IP:44264 remote=54.240.251.223:443
<http://54.240.251.223:443> ORIGINAL_DST FD 28 flags=1 |
|2022/11/29 10:32:38.943 kid1| 83,5| PeekingPeerConnector.cc(273)
startTunneling: will tunnel instead of negotiating TLS|
It is clear that in creates the tunnel so the 500 probably is that
error? Why the bump/sni messages never log anything (according to
https://wiki.squid-cache.org/Features/SslPeekAndSplice
<https://wiki.squid-cache.org/Features/SslPeekAndSplice> they should
log splice not -). This is the config for bumping:
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
.... http rules ...
acl allowed_https_sites ssl::server_name_regex
"/etc/squid/whitelist.txt"
ssl_bump peek step2 allowed_https_sites
ssl_bump splice step3 allowed_https_sites
ssl_bump terminate step2 all
Ip tables simply redirect:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT
--to-port 3129
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT
--to-port 3130 # https port on squid: https_port 3130 intercept
ssl-bump cert=/etc/squid/ssl/dummy.pem
Thanks in advance, i have been trying this for a week now reading a
lot of posts but not luck...
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
