[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867468#comment-13867468
]
Wei Sun commented on TS-2480:
-----------------------------
Hi James, I attached a small patch. Basically, the assumption is that session
ticket information(key_file, session_ticket_enabled) is tied to an address
configured in ssl_multicert.config, I added a log to inform users if they break
the assumption. For SNI/non-SNI supported browsers, the behavior is not changed:
1) request presenting SNI ext, it still overwrites the SSL_CTX in terms of
servername in ClientHello (ticket key information is not much useful in SNI
handling).
2) request doesn't present SNI ext, it retrieves the SSL_CTX according the
address. (If multiple lines in ssl_multicert.config beginning with a same
address, last address will win).
Please let me know your thoughts. Thanks.
> 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)
