On 13/03/20 12:15 am, Vieri wrote: > Hi, > > I'm trying to understand what could cause Squid not to connect to the following site: > > 2020/03/12 11:48:24.115 kid1| 17,4| AsyncCallQueue.cc(55) fireNext: entering FwdState::ConnectedToPeer(0x561b8b5c7918, local=10.215.144.48:51303 remote=1.2.3.4:443 FD 784 flags=25, 0x561b8a7ee5b8/0x561b8a7ee5b8) > 2020/03/12 11:48:24.115 kid1| 17,4| AsyncCall.cc(37) make: make call FwdState::ConnectedToPeer [call219229] > 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8b5c7918 > 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8b5c7918 > 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8a7ee5b8 > 2020/03/12 11:48:24.115 kid1| 17,3| FwdState.cc(447) fail: ERR_SECURE_CONNECT_FAIL "Service Unavailable" > 1.2.3.4:443 > > > A direct connection by-passing Squid shows that the https site opens fine but with a 3DES cipher. In my Squid 4 test I set this temp values just in case: > tls_outgoing_options > flags=DONT_VERIFY_PEER Prevents TLS security being checks. Any problems will be hidden from the proxy admin and logs. They still break TLS. You just wont be told what happened. This is pretty much the opposite of what you want to be doing. > cipher=ALL Enables OpenSSL ciphers that client or server may may detect as forbidden and trigger termination. eg ROT13 and NUL encryption. If you leave this unset instead, Squid's library will use the machines default ciphers. You need to see what those are to know which ciphers to add or remove to fix any problem with the set. > options=ALL Enables lots of OpenSSL features which are a) experimental - breaking TLS, or b) highly dangerous - breaking TLS, or c) forbidden by an endpoint - terminating TLS. Also the opposite of what you want. Leave unset to see what the library is preferring. Then identify the problem. Then set any specific option you might need for the problem you find. There may be multiple problems leading to the same error message, affecting different transaction(s). So troubleshooting has to be careful here. Find a repeatable request, debug that for one fix. Then see if the error still shows up for other traffic and repeat to find the second problem, etc. > > I don't know how to interpret the messages previous to the ERR_SECURE_CONNECT_FAIL line. Do I need to send them all? Which debug options would be more useful? > The [call219229] is the ID of a Call informing FwdState of the problem. Find where it was a) created, and b) scheduled to 'dial'. That will tell you what operation was happening that hit the problem. It may be the source, or may have received info from somewhere else - trace backwards until you find the start of the error handlers. NP: debug info in the TLS logic is a bit absent so you may find it more useful or faster to get a packet dump and inspect with with Wireshark. If you do not know what a message means and unsure it can be helpful to include just in case. All messages from *one* transaction should be sufficient to see the problem with that transaction. Note though this list has a 100KB limit on total mail size to avoid hugs log posts being posted to everyone. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
