[
https://issues.apache.org/jira/browse/TS-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3597:
-------------------------------
Attachment: TS-3597.diff
Found the problem. We were assuming that the SSLNetVConnection object was
initialized when it was allocated. In the case of the accept thread this was
the case because the global allocated was used. But without the accept thread,
the thread allocator is used and THREAD_ALLOC was called instead of
THREAD_ALLOC_INIT. If the object came off the free list, the
sslHandshakeHookState variable was not in the initial state so the certificate
selection did not occur as designed.
TS-3597.diff includes the fix for this and the related missing lock (tracked as
a separate bug). Will work on getting both fixes pushed.
> TLS can fail accept / handshake since commit 2a8bb593fd
> -------------------------------------------------------
>
> Key: TS-3597
> URL: https://issues.apache.org/jira/browse/TS-3597
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
> Reporter: Leif Hedstrom
> Assignee: Susan Hinrichs
> Priority: Critical
> Fix For: 6.0.0
>
> Attachments: TS-3597.diff
>
>
> At least under certain conditions (slightly unclear,but possible a race with
> multiple NUMA nodes), we fail to accept / TLS handshake. I've tracked this
> down to the commit from 2a8bb593fdd7ca9125efad76e27f3f17f5bca794.
> The commit prior to this does not expose the problem. [~gancho] also
> discovered that this problem is only triggered when accept thread is off (0).
> Also from [~gancho], when this reproduces, a command like e.g. this will fail
> the handshake completely (no ciphers):
> {code}
> openssl s_client -connect 10.1.2.3:443 -tls1 -servername some.host.com
> {code}
> Also, since this only happens with accept thread off (0), which implies
> accept on every ET_NET thread, maybe there's some sort of race condition
> going on here? That's just a wild speculation though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
