[ https://issues.apache.org/jira/browse/TS-4263?focusedWorklogId=27445&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-27445 ]
ASF GitHub Bot logged work on TS-4263: -------------------------------------- Author: ASF GitHub Bot Created on: 30/Aug/16 16:42 Start Date: 30/Aug/16 16:42 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_r76832926 --- Diff: iocore/net/SSLUtils.cc --- @@ -95,6 +95,8 @@ struct ssl_user_config { ssl_user_config() : opt(SSLCertContext::OPT_NONE) { REC_ReadConfigInt32(session_ticket_enabled, "proxy.config.ssl.server.session_ticket.enable"); + REC_ReadConfigStringAlloc(ticket_key_filename, "proxy.config.ssl.server.ticket_key.filename"); + Debug("ssl", "ticket key filename %s", (const char *)ticket_key_filename); } int session_ticket_enabled; // ssl_ticket_enabled - session ticket enabled --- End diff -- Sure :) Issue Time Tracking ------------------- Worklog Id: (was: 27445) Time Spent: 3h (was: 2h 50m) > 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: 3h > 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)