You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2016/04/06 22:19:25 UTC
[jira] [Updated] (TS-4263) Session tickets keys in
ssl_multicert.config do not work with SNI discovered hosts
[ https://issues.apache.org/jira/browse/TS-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-4263:
------------------------------
Fix Version/s: (was: 6.2.0)
7.0.0
> 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
> Labels: A
> Fix For: 7.0.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)