[ https://issues.apache.org/jira/browse/TS-4263?focusedWorklogId=27444&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-27444 ]
ASF GitHub Bot logged work on TS-4263: -------------------------------------- Author: ASF GitHub Bot Created on: 30/Aug/16 16:35 Start Date: 30/Aug/16 16:35 Worklog Time Spent: 10m Work Description: Github user persiaAziz commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/938#discussion_r76831604 --- Diff: iocore/net/SSLUtils.cc --- @@ -544,7 +547,64 @@ ssl_context_enable_ecdh(SSL_CTX *ctx) return ctx; } +static ssl_ticket_key_block * +ssl_create_ticket_keyblock(const char *ticket_key_path) --- End diff -- Yes most of the code are duplicated from the ssl_context_enable_tickets, but in this function I am just creating the key block not enabling session ticket for any particular context, So I decided to make a separate function. What we can do is have ssl_context_enable_ticket call ssl_create_ticket_keyblock. That way the code will look cleaner Issue Time Tracking ------------------- Worklog Id: (was: 27444) Time Spent: 2h 50m (was: 2h 40m) > 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: Syeda Persia Aziz > Labels: A > Fix For: 7.0.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > 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)