[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294173#comment-14294173
]
Susan Hinrichs commented on TS-2480:
------------------------------------
The issue is that information about the connections should not be keyed by the
SSL_CTX, because the SSL_CTX might change later.
It looks like Wei Sun was adding indirection in his patch. In implementing
TS-3006, we also changed the lookup structure point to a data structure that
includes the SSL_CTX rather than the SSL_CTX directly. This means we can add
other data like whether the object should be blind tunneled. We could also add
the ticket information here. Rather than pulling up the key information by
indexing via a SSL_CTX that might have changed, we can pull up the key
information by IP address which should be consistent
I assume that the ticket information can only be specified by IP address in the
SSL_multicert file. Since the ticket callback could be processed before the
SNI callback, it doesn't seem that you would always have access to the server
name at this point.
> Choose the address related SSL_CTX for session ticket callback
> --------------------------------------------------------------
>
> Key: TS-2480
> URL: https://issues.apache.org/jira/browse/TS-2480
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
> Reporter: Wei Sun
> Assignee: Susan Hinrichs
> Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-2480.diff
>
>
> When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX
> retrieved from the request when presenting session ticket or session id is
> not associated with any app data (certs, settings, etc), ats delays the
> association in SNI handling. So in the callback of
> SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the
> expected SSL_CTX, and session ticket handling will be degraded to the default
> behavior.
> I have a requirement of retrieving SSL_CTX during these two callback
> functions, probably I could workaround it by
> SSLCertificateConfig::acquire()->findInfoInHash(ip) in every callback and get
> the expected SSL_CTX. I'm wondering is it feasible to do it once in
> make_ssl_connection()? Is there any design consideration for being this
> (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it
> is needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
