You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Susan Hinrichs <sh...@network-geographics.com> on 2015/02/04 19:15:20 UTC
Question about SSL Session Ticket Use Cases and request for opinions
on expansions
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.
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.
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.
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.
Re: Question about SSL Session Ticket Use Cases and request for opinions
on expansions
Posted by Susan Hinrichs <sh...@network-geographics.com>.
Hi Bin,
Thanks for the comments. Some additional questions and comments inline.
On 2/4/2015 1:21 PM, Bin Zeng wrote:
> Hi Susan,
>
> This is Bin. I wrote the initial code for SSL ticket key rotation which was recently committed.
> See TS-3301 and TS-3309. Disclaimer: I am still relatively new to ATS. My understanding is
> limited.
>
> * Before the patch, there was no way to rotate ticket keys in flight. In order to do that, you had to
> put a new key in the ticket key file and then do a ATS restart. Now, you can push a new key to
> the ticket key file and do a hot update with "traffic_line -x". Definitely, ATS server deployments
> did not rotate ticket keys frequently enough. I did some survey into other vendors. Google rotates
> their ticket keys about every 100800 seconds (28 hours), Twitter every 129600 seconds (36 hours).
> Facebook rotates their ticket keys every 86000 seconds (about 24 hours).
>
> * Storing the ticket keys on a persistent disk is not optimal in the point view of security. The keys
> can be stored in ATS memory, a ram file system, or a persistent file system (disk). A ram file system
> is similar to a persistent disk from the view of ATS, except that it is only stored in memory (it cannot
> even be swapped to disk by the OS). Storing the keys in a file system has the benefits of keeping the
> keys across ATS restarts. It would lose all the keys if they were stored in ATS memory.
>
> Question 1: it is somewhat valuable to give people the option to have ATS generate ticket keys.
> The concern is that if you have many ATS boxes and do not have sticky routing, a request can be
> routed to a different ATS instance the next time and the SSL session would not be able to be resumed
> because every ATS generates its own ticket keys. That said, if we can syn all the ticket keys among
> ATS instances conveniently, it would make more sense.
Syncing keys sounds like clustering, and many folks probably don't want
to go there. I think auto-generating keys and offering a simple
lifetime enforcement would only apply to smaller installations.
>
> Question 2: If I understand correctly, ATS/OpenSSL uses proxy.config.ssl.session.cache.timeout as the
> lifetime for a session ticket. The current implementation lets the administrator control the ticket key lifetime
> through "traffic_line -x". For example, if you decide to rotate the ticket key, you can generate a new ticket key
> and push it to the head of ticket key file. You can remove an old key from the tail of the file to retire it completely.
> The current implementation uses the first key in the ticket key file to encrypt session tickets and all the ticket keys
> to decrypt session tickets. If you would like to retire a key completely, you remove it from the file and then do
> a "traffic_line -x".
Thanks for pointer to proxy.config.ssl.session.cache.timeout. Wasn't
aware of that one. That sets the lifetime of the SSL session itself.
Not the lifetime of the ticket key. One ticket key could be used to
state of multiple sessions to create session tickets.
>
> Question 3: I am not sure how many plugin writers will use this. Based on my own experience, they seldom
> touch SSL/TLS stuff.
Yes, that seems to be the consensus so far. Sounds like the file API
that you have now is the good point for integration.
>
> Bin
>
> ________________________________________
> From: Susan Hinrichs [shinrich@network-geographics.com]
> Sent: Wednesday, February 04, 2015 10:15 AM
> To: dev@trafficserver.apache.org
> Subject: Question about SSL Session Ticket Use Cases and request for opinions on expansions
>
> 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.
>
> 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.
>
> 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.
>
> 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.
RE: Question about SSL Session Ticket Use Cases and request for
opinions on expansions
Posted by Bin Zeng <bz...@linkedin.com.INVALID>.
Hi Susan,
This is Bin. I wrote the initial code for SSL ticket key rotation which was recently committed.
See TS-3301 and TS-3309. Disclaimer: I am still relatively new to ATS. My understanding is
limited.
* Before the patch, there was no way to rotate ticket keys in flight. In order to do that, you had to
put a new key in the ticket key file and then do a ATS restart. Now, you can push a new key to
the ticket key file and do a hot update with "traffic_line -x". Definitely, ATS server deployments
did not rotate ticket keys frequently enough. I did some survey into other vendors. Google rotates
their ticket keys about every 100800 seconds (28 hours), Twitter every 129600 seconds (36 hours).
Facebook rotates their ticket keys every 86000 seconds (about 24 hours).
* Storing the ticket keys on a persistent disk is not optimal in the point view of security. The keys
can be stored in ATS memory, a ram file system, or a persistent file system (disk). A ram file system
is similar to a persistent disk from the view of ATS, except that it is only stored in memory (it cannot
even be swapped to disk by the OS). Storing the keys in a file system has the benefits of keeping the
keys across ATS restarts. It would lose all the keys if they were stored in ATS memory.
Question 1: it is somewhat valuable to give people the option to have ATS generate ticket keys.
The concern is that if you have many ATS boxes and do not have sticky routing, a request can be
routed to a different ATS instance the next time and the SSL session would not be able to be resumed
because every ATS generates its own ticket keys. That said, if we can syn all the ticket keys among
ATS instances conveniently, it would make more sense.
Question 2: If I understand correctly, ATS/OpenSSL uses proxy.config.ssl.session.cache.timeout as the
lifetime for a session ticket. The current implementation lets the administrator control the ticket key lifetime
through "traffic_line -x". For example, if you decide to rotate the ticket key, you can generate a new ticket key
and push it to the head of ticket key file. You can remove an old key from the tail of the file to retire it completely.
The current implementation uses the first key in the ticket key file to encrypt session tickets and all the ticket keys
to decrypt session tickets. If you would like to retire a key completely, you remove it from the file and then do
a "traffic_line -x".
Question 3: I am not sure how many plugin writers will use this. Based on my own experience, they seldom
touch SSL/TLS stuff.
Bin
________________________________________
From: Susan Hinrichs [shinrich@network-geographics.com]
Sent: Wednesday, February 04, 2015 10:15 AM
To: dev@trafficserver.apache.org
Subject: Question about SSL Session Ticket Use Cases and request for opinions on expansions
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.
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.
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.
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.
Re: Question about SSL Session Ticket Use Cases and request for opinions on expansions
Posted by James Peach <jp...@apache.org>.
> On Feb 4, 2015, at 11:34 AM, Susan Hinrichs <sh...@network-geographics.com> wrote:
>
>
> On 2/4/2015 12:57 PM, James Peach wrote:
>>> On Feb 4, 2015, at 10:15 AM, Susan Hinrichs <sh...@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
>>
>
Re: Question about SSL Session Ticket Use Cases and request for opinions
on expansions
Posted by Susan Hinrichs <sh...@network-geographics.com>.
On 2/4/2015 12:57 PM, James Peach wrote:
>> On Feb 4, 2015, at 10:15 AM, Susan Hinrichs <sh...@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.
>
>> 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.
>
>> 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.
>
>> 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
>
Re: Question about SSL Session Ticket Use Cases and request for opinions on expansions
Posted by James Peach <jp...@apache.org>.
> On Feb 4, 2015, at 10:15 AM, Susan Hinrichs <sh...@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.
>
> 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.
> 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.
> 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.
J
Re: Question about SSL Session Ticket Use Cases and request for opinions on expansions
Posted by Yongming Zhao <mi...@gmail.com>.
yeah, the cluster wide ticket reuse is what we need in big site, and here is what we tried: https://cwiki.apache.org/confluence/display/TS/SSLSessionResumption, we planed that maybe a small trick on cluster cache is a quickly solution for that purpose.
FYI
> 在 2015年2月5日，上午2:36，Leif Hedstrom <zw...@apache.org> 写道：
>
>>
>> On Feb 4, 2015, at 11:15 AM, Susan Hinrichs <sh...@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.
>
>
> But that means that if you have 100 boxes behind an SLB VIP, your chance of getting a ticket session reused is 1% ? That seems weak at best?
>
>>
>> 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.
>>
>> 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.
>
> Seems reasonable.
>
>
> I’m somewhat skeptical on the usability in large deployments (e.g. Yahoo), if the session key is “random” across all boxes in a VIP. And on the flip side, if there’s a shared seed, then that has the same problem as we have now. How does HTTPD deal with this? Or they simply don’t ?
>
> We would have the option of adding something to cluster configuration, to distribute the session key. But, that’s rarely used, and has some strange requirements (multicast). With a plugin API, at least someone could implement some sort of message protocol to share the (newly) generated session keys with all peers.
>
>
> — Leif
- Yongming Zhao 赵永明
Re: Question about SSL Session Ticket Use Cases and request for opinions
on expansions
Posted by Susan Hinrichs <sh...@network-geographics.com>.
On 2/4/2015 12:36 PM, Leif Hedstrom wrote:
>> On Feb 4, 2015, at 11:15 AM, Susan Hinrichs <sh...@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.
>
> But that means that if you have 100 boxes behind an SLB VIP, your chance of getting a ticket session reused is 1% ? That seems weak at best?
Agreed, generating on the fly is not a solution for large deployments
that are sharing sessions. But for small deployments or people just
evaluating, this seems like a friendlier, more secure stance.
>
>> 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.
>>
>> 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.
> Seems reasonable.
>
>
> I’m somewhat skeptical on the usability in large deployments (e.g. Yahoo), if the session key is “random” across all boxes in a VIP. And on the flip side, if there’s a shared seed, then that has the same problem as we have now. How does HTTPD deal with this? Or they simply don’t ?
As far a I can tell Httpd gives you the file option, and it is up to you
to update files as necessary.
>
> We would have the option of adding something to cluster configuration, to distribute the session key. But, that’s rarely used, and has some strange requirements (multicast). With a plugin API, at least someone could implement some sort of message protocol to share the (newly) generated session keys with all peers.
I think the plugin would allow for some good experimentation. There is
always the possibility of folding a solution back into the core.
>
> — Leif
>
Re: Question about SSL Session Ticket Use Cases and request for opinions on expansions
Posted by Leif Hedstrom <zw...@apache.org>.
> On Feb 4, 2015, at 11:15 AM, Susan Hinrichs <sh...@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.
But that means that if you have 100 boxes behind an SLB VIP, your chance of getting a ticket session reused is 1% ? That seems weak at best?
>
> 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.
>
> 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.
Seems reasonable.
I’m somewhat skeptical on the usability in large deployments (e.g. Yahoo), if the session key is “random” across all boxes in a VIP. And on the flip side, if there’s a shared seed, then that has the same problem as we have now. How does HTTPD deal with this? Or they simply don’t ?
We would have the option of adding something to cluster configuration, to distribute the session key. But, that’s rarely used, and has some strange requirements (multicast). With a plugin API, at least someone could implement some sort of message protocol to share the (newly) generated session keys with all peers.
— Leif