[squid-dev] Broken trunk after r14735, r14726

[Amos Jeffries]

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