On 07/16/2016 06:56 AM, Amos Jeffries wrote: > On 16/07/2016 7:02 a.m., Alex Rousskov wrote: >> * After r14726 (GnuTLS: support for TLS session resume): Squid segfaults >> when attempting to connect to a Secure ICAP service. Official Squid >> v4.0.12 suffers from this bug.
>> * segfault when attempting to connect to a Secure ICAP REQMOD service >> (tested with r14726, r14734): > Does this patch fix the session issue ? No, it does not fix the bug in my test. Same backtrace, same "impossible" zero ssl->references value. Please note that it is easy to test this using stunnel. You do not even need an ICAP server AFAICT -- any server (e.g., nc) would work because the bug is triggered before the ICAP request is sent. ---------------- icap_enable on icap_service service_req reqmod_precache bypass=0 icaps://127.0.0.1:1345/request adaptation_access service_req allow all $ sudo stunnel -f -d 127.0.0.1:1345 -r 127.0.0.1:1344 -p ssl/CA-priv+pub.pem ---------------- > I'm a little worried about the code calling SetSessionResumeData. > OpenSSL documentation states: > "If there is already a session set inside ssl (because it was set with > SSL_set_session() before or because the same ssl was already used for a > connection), SSL_SESSION_free() will be called for that session." > > But our SetSessionResumeData() is called after setting up the sessions > host data, etc. So I'm thinking all that setup in > Ssl::BlindPeerConnector::initializeTls() may be thrown away by the > resume action being called. I cannot validate your concerns without doing a lot of research but I hope that Christos will weigh in. Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
