[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874730#comment-13874730
]
Wei Sun commented on TS-2480:
-----------------------------
Yes, it is related to the order of callbacks invoked by openssl. If the client
presents a non-empty ticket, session ticket callback is invoked prior to SNI
callback. Otherwise, the order is in reverse. It's a problem if the serverName
extension causes a new SSL context to be selected, and I'm wondering is there a
good reason to tolerate the following case:
dest_ip=x.x.x.1 ssl_cert_name=server1.pem // include alternate name1
dest_ip=x.x.x.2 ssl_cert_name=server2.pem // include alternate name2
A client connects to x.x.x.1 and presents ServerName ext: 'name2'.
I'd like to make a simple fix for the session ticket case in the short run,
recreated a patch in the attachment.
I can update it if TS-2031 is a need in here.
> 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)
