[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873516#comment-13873516
]
Wei Sun commented on TS-2480:
-----------------------------
Thanks for the reply. I was trying to address two issues in the small patch.
1) when dest_ip is not configured with '*', session ticket cannot be shared
across servers (e.g. multiple servers behind VIP); 2) In the call back prior to
sni call back, I'd like to retrieve the address associated ctx. The proposal is
to bring the logic of 'lookup ctx in terms of IP address' to the beginning of
creating new SSL object.
Yeah, SNI callback will always be called, and for the second case - 'client
doesn't present servername', the final retrieved ctx is the same as expected in
the previous behavior.
For the alerting log, do you mean TS-2031? I believe someone will work on
that.. Incorporating the fix in here is fine..
> Choose the ip related SSL_CTX not the default when creating new ssl
> --------------------------------------------------------------------
>
> Key: TS-2480
> URL: https://issues.apache.org/jira/browse/TS-2480
> Project: Traffic Server
> Issue Type: Wish
> Components: SSL
> Reporter: Wei Sun
> Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS2480.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.1.5#6160)
