TCP SSL session resumption
Misha Efimov
Ryan Sleevi
On Feb 16, 2015 3:44 AM, "Misha Efimov" <m...@chromium.org> wrote:
>
> IIUC the SSL session resumption info is currently stored in memory and not persisted on disk.
>
> Is this correct?
Yes.
>
> If yes, then does it make any sense to persist it for the benefits of mobile devices (where app gets evicted all too often), and if yes, do we have plans to do so?
>
Maybe. And maybe.
The first maybe is contingent upon disk performance beating CPU and latency. For mobile, we would naively assume this to be true, but I know you know first hand how wildly variable this is. More data is needed before we can definitively state. For example, optimizing for session resumption might cause us to block multiple sockets, and further, might delay us from dully activating the radio. It's weird to think that sending more data could be good, but for mobile, it can be.
On a more pertinent matter is the security ramifications of doing so. Through TLS 1.2, session resumption inherently means storing the master secret for the session (TLS1.3 is playing with the idea of changing this). An attacker who can get the master secret can undo any forward-secret negotiations. This is why protecting and rotating session tickets (on the server side) is so security sensitive.
Now consider this applied to mobile, where files and data are never truly erased (at least, when using flash storage). Mark a block free, move on - don't zero the data. Etc. So you need to protect these keys at rest, which means another key. You have to choose it to be strong enough to protect your strongest session, but it also needs to be ephemeral. And it itself will be high value.
There's some tricks you can do on Android to help with this (using program state and the like), but you want to ensure it's protected, doesn't survive a power cycle, is appropriately secure (TPM?), etc. Last I looked, more work at the OS level is needed to be able to support those sorts of security goals. I'm not entirely sure the status on iOS's capabilities here, but the same concerns would apply.
As to whether we have plans, well, I had it listed for an intern project, but I wasn't able to convince them to work on it (vs the dozen or so other ideas related to TLS performance). One of the other efforts - holding back TLS sessions until a resumable session was ready (e.g. a precursor to loading said session from disk) did not yield positive performance gains. No one is currently working on it, nor do I think anyone should until they have a positive, vetted plan on the security front. Otherwise, they're making the security weaker, and that's no good, even for experiments.
Misha Efimov
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvYwYjTMe04aHEbg30G8jQf%3D1UrOLjD5awjfTCkJ0omAsg%40mail.gmail.com.
Egor Pasko
On Feb 16, 2015 3:44 AM, "Misha Efimov" <m...@chromium.org> wrote:
>
> IIUC the SSL session resumption info is currently stored in memory and not persisted on disk.
>
> Is this correct?Yes.
>
> If yes, then does it make any sense to persist it for the benefits of mobile devices (where app gets evicted all too often), and if yes, do we have plans to do so?
>Maybe. And maybe.
The first maybe is contingent upon disk performance beating CPU and latency. For mobile, we would naively assume this to be true, but I know you know first hand how wildly variable this is. More data is needed before we can definitively state. For example, optimizing for session resumption might cause us to block multiple sockets, and further, might delay us from dully activating the radio. It's weird to think that sending more data could be good, but for mobile, it can be.
On a more pertinent matter is the security ramifications of doing so. Through TLS 1.2, session resumption inherently means storing the master secret for the session (TLS1.3 is playing with the idea of changing this). An attacker who can get the master secret can undo any forward-secret negotiations. This is why protecting and rotating session tickets (on the server side) is so security sensitive.
Now consider this applied to mobile, where files and data are never truly erased (at least, when using flash storage). Mark a block free, move on - don't zero the data. Etc. So you need to protect these keys at rest, which means another key. You have to choose it to be strong enough to protect your strongest session, but it also needs to be ephemeral. And it itself will be high value.
There's some tricks you can do on Android to help with this (using program state and the like), but you want to ensure it's protected, doesn't survive a power cycle, is appropriately secure (TPM?), etc. Last I looked, more work at the OS level is needed to be able to support those sorts of security goals. I'm not entirely sure the status on iOS's capabilities here, but the same concerns would apply.
As to whether we have plans, well, I had it listed for an intern project, but I wasn't able to convince them to work on it (vs the dozen or so other ideas related to TLS performance). One of the other efforts - holding back TLS sessions until a resumable session was ready (e.g. a precursor to loading said session from disk) did not yield positive performance gains. No one is currently working on it, nor do I think anyone should until they have a positive, vetted plan on the security front. Otherwise, they're making the security weaker, and that's no good, even for experiments.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
Ryan Sleevi
On Feb 16, 2015 8:33 AM, "Egor Pasko" <pa...@chromium.org> wrote:
>
>
>
> On Mon, Feb 16, 2015 at 12:59 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>>
>> On Feb 16, 2015 3:44 AM, "Misha Efimov" <m...@chromium.org> wrote:
>> >
>> > IIUC the SSL session resumption info is currently stored in memory and not persisted on disk.
>> >
>> > Is this correct?
>>
>> Yes.
>>
>> >
>> > If yes, then does it make any sense to persist it for the benefits of mobile devices (where app gets evicted all too often), and if yes, do we have plans to do so?
>> >
>>
>> Maybe. And maybe.
>>
>> The first maybe is contingent upon disk performance beating CPU and latency. For mobile, we would naively assume this to be true, but I know you know first hand how wildly variable this is. More data is needed before we can definitively state. For example, optimizing for session resumption might cause us to block multiple sockets, and further, might delay us from dully activating the radio. It's weird to think that sending more data could be good, but for mobile, it can be.
>>
>> On a more pertinent matter is the security ramifications of doing so. Through TLS 1.2, session resumption inherently means storing the master secret for the session (TLS1.3 is playing with the idea of changing this). An attacker who can get the master secret can undo any forward-secret negotiations. This is why protecting and rotating session tickets (on the server side) is so security sensitive.
>>
>> Now consider this applied to mobile, where files and data are never truly erased (at least, when using flash storage). Mark a block free, move on - don't zero the data. Etc. So you need to protect these keys at rest, which means another key. You have to choose it to be strong enough to protect your strongest session, but it also needs to be ephemeral. And it itself will be high value.
>>
>> There's some tricks you can do on Android to help with this (using program state and the like), but you want to ensure it's protected, doesn't survive a power cycle, is appropriately secure (TPM?), etc. Last I looked, more work at the OS level is needed to be able to support those sorts of security goals. I'm not entirely sure the status on iOS's capabilities here, but the same concerns would apply.
>
> Naive non-expert question: Can we trust Android/iOS flash encryption for SSL session resumption?
>
> Android claims using Trusted Execution Environment’s (TEE), which uses the same idea as Trusted Platform Module (TPM?) you mentioned above:
> https://source.android.com/devices/tech/security/encryption/
There are... complexities... there. No, it doesn't use a TPM, not everywhere, and no, the guarantees aren't as strong as we (Chrome) would want when storing effectively PFS keys indefinitely.