On 17/07/2016 4:35 a.m., Alex Rousskov wrote: > 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. >
Thanks. I'm reverting the session change from trunk until I can replicate and do better testing of it. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
