[squid-dev] Broken trunk after r14735, r14726

Alex Rousskov rousskov at measurement-factory.com
Sat Jul 16 16:35:25 UTC 2016


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.



More information about the squid-dev mailing list