[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