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

41–49 of 49 posts

Re: TLS 1.2 Session Tickets

#41

Post by e12e »

Hello71 wrote: post #40
e12e wrote: post #32

Earlier quoted context omitted.

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.

Yes, I wasn't trying to say rotation is useless - just highlight that n servers still lead to n avenues of getting at traffic for all n servers, and that cloudflare did something to deal with the pfs issue. It's worse than n servers without session resumption, but better than it could be.

[ed: per https://news.ycombinator.com/item?id=15360922 the window is 18 hours]

Re: TLS 1.2 Session Tickets

#42

Post by sdevlin »

prdonahue wrote: post #39
sdevlin wrote: post #8

Earlier quoted context omitted.

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 a…

These are great details, but they don't really answer my question.

Re: TLS 1.2 Session Tickets

#43

Post by cesarb »

Panino wrote: post #31
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 a…

> It's already more or less phased out.

Was TLS 1.1 ever "phased in"? It was the "most recent" TLS version for only a couple of years, so the early adopters went quickly to TLS 1.2, while the late adopters stayed at TLS 1.0 (or even "TLS 1.0 but disabled by default, therefore actually SSL 3.0"). Once the later adopters catch up, there's no reason for them to not jump directly to TLS 1.2.

Re: TLS 1.2 Session Tickets

#44

Post by smegel »

xenophonf wrote: post #11
xenophonf wrote: post #10

So if like me you want to know how to disable session tickets in Apache httpd, you need to be running at least httpd 2.4.8 with OpenSSL 1.0.2. Then you can set: SSLOpenSSLConfCmd Options -SessionTicket Alternatively, if you're running at least httpd 2.4.11 with OpenSSL 0.9.8f, you can set this instead: SSLSessionTickets off See also: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopenss... https://httpd.apache…

Also, if you're running RHEL/CentOS 7, you'll want to switch to the SCL version of Apache httpd (2.4.25) as the version in the base repositories (2.4.6) is too old to support either setting: https://www.softwarecollections.org/en/scls/rhscl/httpd24/

Well, technically RHEL7 runs httpd-2.4.6-67, which is RedHat's 67th patched version of 2.4.6.

They backport a lot of stuff from later versions, don't see why they could not have done this (they haven't, I checked).

Re: TLS 1.2 Session Tickets

#45

Post by bearhsiung »

NewSessionTicket is sent before ChangeCipherSpec means the message is not encrypted using the master secret exchanged with the handshake and is not necessary means that the session ticket is in plaintext. Quite contrary, it has been encrypted using the server secret key. In the page 3 of RFC5077, it states "a ticket that is encrypted and integrity-protected by a key known only to the server." and in the page 11, "Tickets must be authenticated and encrypted to prevent modification or eavesdropping by an attacker."

Re: TLS 1.2 Session Tickets

#46

Post by vbernat »

The article and the comments here lack a bit of context. At the time where tickets were starting to be deployed (around 2011), ECDH ciphers were not in use and PFS was therefore quite expensive (and therefore, almost never used). Around the same time, the move from 1024-bit certificates to 2048-bit certificates were making TLS difficult to deploy at scale for everyone except Google.

Session tickets were primarily a mechanism to help to reduce to load of TLS connections. The reduced latency is a happy side-effect. At the time, it was already well-known that this would negatively impact PFS (something I already mention in my own blog article about session tickets in 2011).

Moreover, many seem to build a scenario where session tickets are recovered by an attacker but not the private keys. Usually, session tickets are in memory only and private keys are persisted. This makes those tickets more unlikely to be recovered by anyone unless you get access to a running web server. In this case, you have far more serious trouble than those tickets (even if the attacker still cannot decode past recorded data).

Even today, TLS handshakes are quite expensive, both for the server and the clients. Using session tickets (with rotated keys) still outweigh the downsides of not using them. That's why every major site are using them.

Re: TLS 1.2 Session Tickets

#47

Post by gruturo »

ramshanker wrote: post #19

We are doing all these session tickets gymnastic to reduce the round trip. Mostly considering web applications. In case of native mobile application, we could just add a splash-screen/quick 2 sec animation hiding the worst case 3x200ms round trip latency overhead. So at the start of the app we simply create a fresh perfectly secured TLS connection. It appears a better choice from security standpoint, UI can always be…

In case of 2.5G connections (I still get 2.5G on a regular basis, e.g. in some specific train stations on my way to work in the morning) it can easily be 800ms per RTT - so 2.4 seconds before you have a chance to request any content.

And no, you cannot really ignore this if you are interested in fostering TLS' adoption in the real world. Every tenth of a second causes a measurable loss in user interest, and in many organizations this metric will drive the decision. We cannot legislate from our ivory tower and expect the world to follow against their (perceived) best interest.

Re: TLS 1.2 Session Tickets

#48

Post by vbernat »

tony101 wrote: post #5

> An attacker with the STEK doesn't need to wait until session resumption is attempted. Session Tickets containing the current session keys are sent at the beginning of every connection that merely supports Session Tickets. In plaintext on the wire, ready to be decrypted with the STEK, fully bypassing Diffie-Hellman. I found this flaw to be the scariest, by far. It means that a connection with "forward secrecy" gives…

This is by design. The primary goal of session tickets is to resume a session without doing excessive crypto (no asymmetric cryptography).

Re: TLS 1.2 Session Tickets

#49

Post by jessaustin »

agl wrote: post #29
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…

We are still working around bugs in network middleware. I hope that it will be available in Chrome and on Google's servers in Q1, 2018.

Is that a euphemism for "waiting for BlueCoat shitboxes to die and get replaced"?
Post reply on HN