> On Aug 5, 2015, at 8:22 AM, Susan Hinrichs <shinr...@network-geographics.com> > wrote: > > 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.
Yes, I think this is a promising approach. > 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. I don't remember what happens without looking at the code, but ISTR there was a time when a reload failure would just log an error preserve the existing configuration. Does that still happen? > 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 >> >> >> >
