[ 
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)

Reply via email to