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.<p>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).<p>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).<p>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.
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:<p><pre><code> SSLOpenSSLConfCmd Options -SessionTicket
</code></pre>
Alternatively, if you're running at least httpd 2.4.11 with OpenSSL 0.9.8f, you can set this instead:<p><pre><code> SSLSessionTickets off
</code></pre>
See also:<p><a href="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd" rel="nofollow">https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopenss...</a><p><a href="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessiontickets" rel="nofollow">https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessio...</a>
> 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.<p>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.
If you're using OpenSSL, you can disable RFC 5077 Session Tickets via SSL_OP_NO_TICKET:<p><a href="https://wiki.openssl.org/index.php/SSL/TLS_Client#Session_Tickets" rel="nofollow">https://wiki.openssl.org/index.php/SSL/TLS_Client#Session_Ti...</a><p>Figuring out how to access that option from your library/language is an exercise for the reader.<p>Looking into this for Python. Python 3 supports sessions and the tickets may be disabled:<p><a href="https://docs.python.org/3/library/ssl.html#ssl.SSLSession" rel="nofollow">https://docs.python.org/3/library/ssl.html#ssl.SSLSession</a><p><a href="https://docs.python.org/3/library/ssl.html#ssl.OP_NO_TICKET" rel="nofollow">https://docs.python.org/3/library/ssl.html#ssl.OP_NO_TICKET</a><p>For Python 2, I see no way to get at the session object (at least on the client side), much less disable session tickets:<p><a href="https://docs.python.org/2/library/ssl.html" rel="nofollow">https://docs.python.org/2/library/ssl.html</a><p>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.<p>Under the covers, requests is using urllib3 and it ends up makes this call if pyOpenSSL is installed:<p><pre><code> urllib3.contrib.pyopenssl.inject_into_urllib3()
</code></pre>
<a href="http://urllib3.readthedocs.io/en/latest/reference/urllib3.contrib.html#module-urllib3.contrib.pyopenssl" rel="nofollow">http://urllib3.readthedocs.io/en/latest/reference/urllib3.co...</a><p>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.<p>Edit: nope, urllib3 doesn't support SSL session re-use. There's an open PR:<p><a href="https://github.com/shazow/urllib3/issues/590" rel="nofollow">https://github.com/shazow/urllib3/issues/590</a>
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?<p>[0] <a href="https://blog.chromium.org/2013/06/experimenting-with-quic.html" rel="nofollow">https://blog.chromium.org/2013/06/experimenting-with-quic.ht...</a>
Hm, looks like maybe a ticket should be filed against:<p><a href="https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices" rel="nofollow">https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...</a><p>As it stands, the point on resumption reads a little on the positive side?:<p>> 3.2 Use Session Resumption<p>> 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.<p>Does http2 have similar issues with session resumption (especially: compromised pfs)?<p>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?<p><a href="https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/" rel="nofollow">https://blog.cloudflare.com/tls-session-resumption-full-spee...</a><p>[ed: also came over this:<p><a href="https://github.com/mozilla/cipherscan" rel="nofollow">https://github.com/mozilla/cipherscan</a><p>Which looks very handy for sanity-checking servers.]
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 ?<p>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.
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.<p>It appears a better choice from security standpoint, UI can always be cleverly tricked into being smooth.
For HAProxy 1.7 (may be present in older versions, didn't check), there's the 'no-ssl-reuse'[0] directive for the server.<p>[0]:<a href="https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#5.2-no-ssl-reuse" rel="nofollow">https://cbonte.github.io/haproxy-dconv/1.7/configuration.htm...</a>
Well, on the bright side h2 and keepalive are other ways of reducing the overall number of tls handhakes required if you're doing http.<p>Too bad session resumption has issues.
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."