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.
SSLOpenSSLConfCmd Options -SessionTicket
SSLSessionTickets off
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopenss...
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessio...
They backport a lot of stuff from later versions, don't see why they could not have done this (they haven't, I checked).
I found this flaw to be the scariest, by far. It means that a connection with "forward secrecy" gives up this property as soon as it begins.
I always assumed the STEK-encrypted session key was sent inside the established TLS PFS stream. To send it outside the stream is mind-numbingly insane!
Browsers should not report connections as having PFS if tickets are enabled in TLS 1.2. This is like NSA slide "PFS added and removed here :-)"
https://wiki.openssl.org/index.php/SSL/TLS_Client#Session_Ti...
Figuring out how to access that option from your library/language is an exercise for the reader.
Looking into this for Python. Python 3 supports sessions and the tickets may be disabled:
https://docs.python.org/3/library/ssl.html#ssl.SSLSession
https://docs.python.org/3/library/ssl.html#ssl.OP_NO_TICKET
For Python 2, I see no way to get at the session object (at least on the client side), much less disable session tickets:
https://docs.python.org/2/library/ssl.html
Under Python 2, pyOpenSSL has better support. You can make use of it on Python2 (and 3) via requests by installing `requests[security]` instead of just `requests`. Using `[security]` causes requests to pull in pyOpenSSL, cryptography and idna packages.
Under the covers, requests is using urllib3 and it ends up makes this call if pyOpenSSL is installed:
urllib3.contrib.pyopenssl.inject_into_urllib3()
That's as far as I've gotten. There's no documentation so it's going to require reading the urllib3 source to figure out what's going on under the hood.
Edit: nope, urllib3 doesn't support SSL session re-use. There's an open PR:
$ 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.
[0] https://blog.chromium.org/2013/06/experimenting-with-quic.ht...
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 nonfunctional session resumption mechanism may introduce a significant performance penalty.
Does http2 have similar issues with session resumption (especially: compromised pfs)?
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?
https://blog.cloudflare.com/tls-session-resumption-full-spee...
[ed: also came over this:
https://github.com/mozilla/cipherscan
Which looks very handy for sanity-checking servers.]
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 scenario is somewhat unlikely in the first place.
So this is what we are stuck with for the time being.
0-RTT doesn't have to use STEKs, there's a better way to do it, but TLS1.3 won't enforce or require it (though it could), so it'll be up to the marketplace of ideas and security standards to sort it out.
0-RTT trades performance at the expense of security properties inside the same tunable protocol, which is the sort of wishy-washy stuff I (and others) were hopeful we'd get away from, the same way PFS ciphersuites went from obscure to preferred overnight, the same way cleartext HTTP has been marginalized, the same way broken ciphersuites were aggressively blacklisted and underused ciphersuites were pruned.
[1] https://tools.ietf.org/html/draft-ietf-httpbis-replay-00
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 using IE7 or something super old. I liked the way Apple had taken a stand with App Transport Security initially but even they backed down and pushed the deadline indefinitely.
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.
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.
It appears a better choice from security standpoint, UI can always be cleverly tricked into being smooth.
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.
[0]:https://cbonte.github.io/haproxy-dconv/1.7/configuration.htm...
Too bad session resumption has issues.