Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS 1.2 Session Tickets

blog.filippo.io

Post reply on HN
Print view View original

31–40 of 49 posts

Re: TLS 1.2 Session Tickets

#31

Post by Panino »

Bhilai wrote: post #22

I understand that TLS 1.3 is in draft stage currently. Is there an expected date of when TLS1.3 is supposed to be available in common libs and browsers ? Also at current rate it sounds like it’s going to take years to phase out TLS 1.1. Would mordern browsers take a stand and refuse to initiate connections for older versions of TLS and its not just browsers right, there are other odd ball clients and enterprises usin…

> Also at current rate it sounds like it’s going to take years to phase out TLS 1.1.

It's already more or less phased out. On my webservers, TLS 1.1 accounts for 0.1% of traffic, and about half of that is junk requests like exploit attempts.

Check out SSL Pulse, specifically the Protocol Support graph:

https://www.ssllabs.com/ssl-pulse/

This used to show 100% support for TLS 1.0, which is now at 92.6% as some sites are now going 1.2-only. That's just webserver support, not usage. Huge real-world difference. Like my car supports not wearing a seal-belt but I always use it. The vast majority of usage is 1.2, and a large percentage of 1.0/1.1 traffic is unwanted garbage traffic. Hence why some people are disabling 1.0/1.1 in their webservers. It also exposes more code for questionable benefit.

BTW I'd love to know what sites support TLS 1.0 but not 1.2. What's the breakdown of the Alexa Top 1000 or so? I suspect it's mostly banks and unknown sites.

Re: TLS 1.2 Session Tickets

#32

Post by e12e »

Hello71 wrote: post #24
e12e wrote: post #23

Hm, looks like maybe a ticket should be filed against: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym... As it stands, the point on resumption reads a little on the positive side?: > 3.2 Use Session Resumption > Session resumption is a performance-optimization technique that makes it possible to save the results of costly cryptographic operations and to reuse them for a period of time. A disabled or non…

> I came across this, which documents how cloudscape does this securely - at least they rotate - but looks like read access to memcache+compromise of a single web server is enough to compromise the past hour or two of ssl traffic that goes through cloudflare? but (depending on how you get in) you can probably also compromise the next few hours, so one extra hour doesn't seem like a huge difference, given that the sce…

It's relevant in terms of pfs. Say, you happen to have ciphertext of all traffic to a domain for the past three years (whitepower.forum.example.ru), and you get an urgent need to read that ciphertext. Now, if you could get physical access to any one cloudflare server, and perhaps dump the ram, or do a cold boot attack - that might have been enough to read all that data. Assume for the sake of argument, that the servers hosting the site is (physically) out of reach.

Re: TLS 1.2 Session Tickets

#33

Post by zaroth »

tptacek wrote: post #30
zaroth wrote: post #28

Earlier quoted context omitted.

True, it does not destroy the entire purpose if and when the STEK is securely and properly rotated. But to call this PFS stretches the truth in ways that boring crypto never does. The number of real-world cases where PFS is reduced exactly to the non-PFS state by the existence of session tickets with fixed STEKs is not only non-zero, but rather I would venture a guess it is staggeringly large. E.g. Configuring Sessio…

The 'P' in 'PFS' has always stretched the truth, which is why a lot of practitioners elide it. Even if you never rotate STEKs and never reset systems to get a new STEK accidentally, the DH handshake is still providing forward secrecy value for clients who don't do session tickets.

Do such clients actually exist in mainstream usage? The one crypto bug which you are actually protected from by using IE on Win7!

Re: TLS 1.2 Session Tickets

#34

Post by tptacek »

zaroth wrote: post #33
tptacek wrote: post #30

Earlier quoted context omitted.

The 'P' in 'PFS' has always stretched the truth, which is why a lot of practitioners elide it. Even if you never rotate STEKs and never reset systems to get a new STEK accidentally, the DH handshake is still providing forward secrecy value for clients who don't do session tickets.

Do such clients actually exist in mainstream usage? The one crypto bug which you are actually protected from by using IE on Win7!

I don't know, but the cost that session tickets are saving are almost entirely an externality to clients, and the privacy benefit of not honoring tickets isn't, so there would seem to be some value to a Chrome extension that busted that cache.

Re: TLS 1.2 Session Tickets

#35

Post by zaroth »

tptacek wrote: post #34
zaroth wrote: post #33

Earlier quoted context omitted.

Do such clients actually exist in mainstream usage? The one crypto bug which you are actually protected from by using IE on Win7!

I don't know, but the cost that session tickets are saving are almost entirely an externality to clients, and the privacy benefit of not honoring tickets isn't, so there would seem to be some value to a Chrome extension that busted that cache.

Yeah but it's not the client sending the resumption ticket but sending the capability in the ClientHello which exposes the session key under a possibly fixed key. So you can't fix this by busting the client cache I think. You need the capability flag off.

Even so could an active adversary turn on the capability in the ClientHello and still get a chance to see the STEK encrypted session key even against legacy (or intentionally ticket-disabled) clients? This I don't know - would a client just drop the ticket message and proceed or would it abort? But at least it would have to be an active attacker.

Re: TLS 1.2 Session Tickets

#36

Post by tptacek »

zaroth wrote: post #35
tptacek wrote: post #34

Earlier quoted context omitted.

I don't know, but the cost that session tickets are saving are almost entirely an externality to clients, and the privacy benefit of not honoring tickets isn't, so there would seem to be some value to a Chrome extension that busted that cache.

Yeah but it's not the client sending the resumption ticket but sending the capability in the ClientHello which exposes the session key under a possibly fixed key. So you can't fix this by busting the client cache I think. You need the capability flag off. Even so could an active adversary turn on the capability in the ClientHello and still get a chance to see the STEK encrypted session key even against legacy (or int…

Yep, this got pointed out to me several times on Slack. Session tickets suck.

Re: TLS 1.2 Session Tickets

#37

Post by tedunangst »

dward wrote: post #20

One of the original goals of Google's QUIC[0] protocol was to achieve 0-RTT handshake. I wonder how TLS 1.{2,3} Session Tickets will affect the future of that protocol. Has it achieved it's purpose (applying the right pressure to the TLS working group)? Will it be phased out now? [0] https://blog.chromium.org/2013/06/experimenting-with-quic.ht...

TLS 1.3 also supports 0 RTT. Subject to some replay attacks, the solution to which is “the application should detect and ignore that.”

Re: TLS 1.2 Session Tickets

#38

Post by baby »

dward wrote: post #20

One of the original goals of Google's QUIC[0] protocol was to achieve 0-RTT handshake. I wonder how TLS 1.{2,3} Session Tickets will affect the future of that protocol. Has it achieved it's purpose (applying the right pressure to the TLS working group)? Will it be phased out now? [0] https://blog.chromium.org/2013/06/experimenting-with-quic.ht...

I felt like Google was not going to move to TLS 1.3 if they had not included 0-RTT. Now that TLS 1.3 has agreed to include it, it seems logical to terminate QUIC crypto.

Re: TLS 1.2 Session Tickets

#39

Post by prdonahue »

sdevlin wrote: post #8
jgrahamc wrote: post #2

Related: https://crypto.dance/projects/6239406

What is Cloud Flare's policy for managing STEKs? Are they distinct per geographic region as the article recommends?

TL/DR: we rotate them every hour, but need to keep history of previous STEKs for 18 hours to support the maximum session lifetime:

$ openssl s_client -connect cloudflare.com:443 2>/dev/null | grep "lifetime hint" TLS session ticket lifetime hint: 64800 (seconds)

--

We've written about how we manage TLS session tickets here: https://blog.cloudflare.com/tls-session-resumption-full-spee....

Additionally, I wrote here about a bug that we encountered with Microsoft's implementation of TLS session resumption: https://blog.cloudflare.com/microsoft-tls-downgrade-schannel....

Here's a snippet from my blog post:

Session Tickets at CloudFlare CloudFlare’s solution to this problem, documented in previous blog posts, is to frequently regenerate and synchronize these session ticket keys across our entire global network. We currently do this once per hour. This means we need a mechanism for turning over session ticket keys. For instance, if a client instantiates an HTTPS session at 12:00pm and continues using that ticket past 1:00pm, our edge network will re-encrypt the ticket with a brand new session ticket key.

To accomplish this, our web servers must have both the full history of all previous keys that could have encrypted the ticket (i.e., one per hour dating back to the maximum session lifetime of 64,800 seconds) as well as immediate access to each newly generated key. The previous keys are used exclusively to decrypt tickets presented by the client, while the new keys are used to "refresh" the encryption on existing tickets and encrypt tickets for entirely new sessions.

Re: TLS 1.2 Session Tickets

#40

Post by Hello71 »

e12e wrote: post #32
Hello71 wrote: post #24

Earlier quoted context omitted.

> I came across this, which documents how cloudscape does this securely - at least they rotate - but looks like read access to memcache+compromise of a single web server is enough to compromise the past hour or two of ssl traffic that goes through cloudflare? but (depending on how you get in) you can probably also compromise the next few hours, so one extra hour doesn't seem like a huge difference, given that the sce…

It's relevant in terms of pfs. Say, you happen to have ciphertext of all traffic to a domain for the past three years (whitepower.forum.example.ru), and you get an urgent need to read that ciphertext. Now, if you could get physical access to any one cloudflare server, and perhaps dump the ram, or do a cold boot attack - that might have been enough to read all that data. Assume for the sake of argument, that the serve…

aiui getting the current keys won't magically let you decrypt those three years of traffic. that's the whole point of rotation.
Post reply on HN