> On Feb 4, 2015, at 11:34 AM, Susan Hinrichs
> <shinr...@network-geographics.com> wrote:
>
>
> On 2/4/2015 12:57 PM, James Peach wrote:
>>> On Feb 4, 2015, at 10:15 AM, Susan Hinrichs
>>> <shinr...@network-geographics.com> wrote:
>>>
>>> As part of integrating in the fix for TS-2480, I'm finally getting my head
>>> around SSL session tickets and how ATS handles them.
>>>
>>> In part of my looking around the web while debugging it seems that there
>>> are some security concerns with session reuse in general and ticket keys in
>>> particular. The two major security concerns for ticket keys and PFS were
>>> * Server deployments don't rotate their ticket keys fast enough
>>> * Storing sensitive ticket key information on disk gives attackers another
>>> point of attack
>>>
>>> Question 1: Would it be valuable to give people the option in ATS to have
>>> ATS generate the ticket key information as an alternative to providing the
>>> ticket key information on the fly. This seems to be the Apache HTTP
>>> approach. They allow the specification of a file. Otherwise, the server
>>> will generate a ticket key on process start. This would be a very minimal
>>> change. I tried it out on my dev build this morning.
>> IIRC that's what OpenSSL does automatically when session tickets are enabled
>> and you don't provide your own ticket key.
>
> Hmm, didn't realize that OpenSSL does this. But just gave it a try, and you
> are correct. It looks like the only way to stop openssl from doing this in
> ATS is to explicitly set ssl_ticket_enable=0 in the ssl_multicert.config.
> But I'm perhaps missing the global disable setting.
There's no global setting.
>>> Question 2: Would it be valuable to implement a ticket key lifetime
>>> parameter? If set and if ATS is generating the ticket keys (see Question
>>> 1), ATS could regenerate the ticket key once it hit the lifetime. Also
>>> provide a parameter to specify how long you will allow tickets encrypted
>>> with the old key, e.g. Set a default of 22 hour key regeneration time with
>>> a 24 hour use time.
>> No. Bin Zeng added ticket key rotation. You don't need a lifetime; just
>> rotate the keys at whatever frequency you desire.
>
> I think this would only be valuable if tickets were auto generated. And that
> would only be beneficial for single proxy installations. While that is not
> valid for large deployments, that would be valid for many ISP deployments.
I don't know. It seems pretty simple to add a cron job that does something like:
dd bs=48 skip=1 if=/path/to/ticket.key of=/path/to/new/ticket.key #
keep the last 3 keys
dd if=/dev/random of=/path/to/new/ticket.key bs=48 conv=notrunc count=1
oskip=3 # append a kew key
mv /path/to/new/ticket.key /path/to/ticket.key
chmod/chown XXX /path/to/ticket.key
touch ssl_multicert.config
traffic_line -x
We can document a recipe to do this. I can see your point WRT implicit ticket
keys though.
>>> Question 3: Would it be valuable to let plugins hook their own code to run
>>> during the session_ticket_key_callback? This would allow a deployment to
>>> override the standard ATS ticket key approach with their own. Potentially
>>> doing more clever ticket key sharing than just using the file system. Or
>>> implementing their own key rotation or generation scheme.
>> This seems to be of pretty limited value. I think that adding Linux kernel
>> key management support would be more generally useful, but in either case,
>> few people would use this.
>
> If you had a plugin interface, people could implement their own interface to
> the Linux kernel key management, or memcached or whatever.
The kernel key management is pluggable, but I have no real object to an API. It
just seems unlikely to be used.
>>> Question 4: What is the granularity of session tickets? In ATS, you can
>>> set session tickets on default or on an IP by IP basis. Do most people
>>> just set one ticket for all possible destinations? Or do folks set tickets
>>> on each IP? No suggestion here. Just curious how the feature is used.
>> Currently, you can only set session tickets at the same granularity as
>> ssl_mulicert.config. There is a records.config setting for using a global
>> ticket (which I think makes sense), but that's not implemented.
>
> Oh, I forgot in the course of my messing around, I added a test in the
> session ticket callback to look at the default entry if there was nothing for
> the specific IP in ssl_multicert.config.
>
> Do most people use the same ticket file for all destinations? Or is it
> desirable to use different ticket files for different destinations?
>
>>
>> J
>>
>
