[jira] [Commented] (TS-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183867#comment-15183867 ] 

Leif Hedstrom commented on TS-4263:
-----------------------------------

The first proposal would basically reduce the lookup mechanism in the callback (ssl_callback_session_ticket) to be

{code}
  ssl_ticket_key_block *keyblock = lookup->find_ticket_keyblock(keyname);

  if (keyblock == NULL) {
    // No keyblock found.  Must fail out at this point.
     return -1;
   }
{code}

And we would completely disassociate the key blocks from the SSLCertContext. I'm still not sure how the ownership around SSLCertContext should work ([~jpeach@apache.org] tried to explain it to me), it  looks odd from the outside with how we create multiple SSLCertContext when inserting them into the lookups.

> Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts
> ----------------------------------------------------------------------------------
>
>                 Key: TS-4263
>                 URL: https://issues.apache.org/jira/browse/TS-4263
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Configuration, SSL
>            Reporter: Leif Hedstrom
>            Assignee: Leif Hedstrom
>              Labels: A
>             Fix For: 6.2.0
>
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI negotiation to get a TLS session, then you can not configure the session ticket keys block, at all. Meaning, there's no way to share the keys across more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At the point of resuming a session, the SSL call back provides the 16 byte key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte key-name, and keep a separate lookup table for the key blocks. This is in itself a little ugly, because the ownerships around SSLCertContext is a little murky. But it seems the cleanest, and definitely seemed to have been the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to remove the ticket_key_name= option from ssl_multicert.config entirely, and only have a single, global key block configured via records.config.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)