I would argue that the specification of the session ticket key in the
ssl_multicert.config file is inappropriate at least as the primary
mechanism. It seems that for the common case, you don't need to use
different session keys for different domains. You could specify one key
file set in records.config. Then you are not reloading
ssl_multicert.config, which I agree for a large file is a somewhat dicey
proposition.
However, there is a setting to allow errors on the ssl_multicert reload
(proxy.config.ssl.server.multicert.exit_on_load_fail) so I don't think
you are condemned to the SSL failure case you outline.
There are several bugs open in the ticket area to simply ticket control:
TS-3528, TS-3371, TS-3742. I'm curious if you have a use case where you
do need to differentiate ticket keys by domains?
I would also lobby for a Plugin interface to update the list of
tickets. This would allow people to implement any reload strategy they
wish. It would also support people who do not want to store ticket keys
through the file system.
On 8/5/2015 5:10 AM, Bret Palsson wrote:
The problem with reloading SSL configuration is if there is a problem with
one of your certs, say a permission issue, ATS will unload all the certs
from the running process and still accept traffic causing SSL errors.
Being able to reload just the keys is much safer than trying to reload the
world, or configs that have changed. Especially since key rotation will
likely be automatic on a schedule.
-Bret
On Tue, Aug 4, 2015 at 8:56 PM, James Peach <jpe...@apache.org> wrote:
On Aug 4, 2015, at 3:30 PM, Nikhil Marathe <nmara...@linkedin.com.INVALID>
wrote:
Hi,
This is Nikhil from Linkedin Engineering.
A Key Rotation feature has been added to TLS session tickets; details:
http://comments.gmane.org/gmane.comp.apache.trafficserver.devel/2084
At present, this feature relies on periodic execution of traffic_line -x
to
reload new keys. However traffic_line -x reloads entire configuration,
and
so has a much wider impact than needed.
In order to address this concern and to localize the impact of reloading
keys, we would like to propose following approach:
ATS will schedule periodic continuation which checks the session ticket
key
file. The reload interval will be records.configurable. If the session
ticket key file has been modified, ATS will reload the keys from the
file.
Hi Nikhil,
At the time we discussed the need for this and my view is still that it is
not necessary. Reloading the SSL configuration should be completely
harmless and it seems very straight forward for the job that populates the
new keys to call traffic_line at the right time.
cheers,
James
