[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872816#comment-13872816
]
James Peach edited comment on TS-2480 at 1/16/14 6:56 PM:
----------------------------------------------------------
OK, this patch appears to be handling 2 separate problems.
First, if the same {{dst_ip}} is specified for more than one
{{ssl_multicert.config}} entry, then it checks that the the ticket key settings
are the same for each one. I don't like that this is checking for just one of a
number of possible error cases. I think that, rather than this patch, we should
fix TS-2031 for the general case where there are overlaps in the certificate
subjects, alternate names or IP addresses.
Second, I believed that OpenSSL always called the SNI callback, even if the
client did not send the server name extension. I checked the OpenSSL source,
and I *think* this is correct; {{ssl_parse_clienthello_tlsext}} always calls
the SNI callback if it is there without depending on whether the server name
extension was sent. Do older versions of OpenSSL behave differently?
On a code review note, {{SSLError}} should only be called in response to errors
from the OpenSSL API.
was (Author: jamespeach):
OK, this patch appears to be handling 2 separate problems.
First, if the same {{dst_ip}} is specified for more than one
{{ssl_multicert.config}} entry, then it checks that the the ticket key settings
are the same for each one. I don't like that this is checking for just one of a
number of possible error cases. I think that, rather than this patch, we should
fix TS-2013 for the general case where there are overlaps in the certificate
subjects, alternate names or IP addresses.
Second, I believed that OpenSSL always called the SNI callback, even if the
client did not send the server name extension. I checked the OpenSSL source,
and I *think* this is correct; {{ssl_parse_clienthello_tlsext}} always calls
the SNI callback if it is there without depending on whether the server name
extension was sent. Do older versions of OpenSSL behave differently?
On a code review note, {{SSLError}} should only be called in response to errors
from the OpenSSL API.
> 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)