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

11–20 of 49 posts

Re: TLS 1.2 Session Tickets

#11

Post by xenophonf »

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/

Re: TLS 1.2 Session Tickets

#12

Post by js2 »

If you're using OpenSSL, you can disable RFC 5077 Session Tickets via SSL_OP_NO_TICKET:

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()
http://urllib3.readthedocs.io/en/latest/reference/urllib3.co...

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:

https://github.com/shazow/urllib3/issues/590

Re: TLS 1.2 Session Tickets

#15

Post by sdevlin »

zaroth wrote: post #13
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?

It says in that deck: Distribute globally, rotate hourly, expire after 18 hours.

So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?

Re: TLS 1.2 Session Tickets

#16

Post by zaroth »

sdevlin wrote: post #15
zaroth wrote: post #13

Earlier quoted context omitted.

It says in that deck: Distribute globally, rotate hourly, expire after 18 hours.

So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?

I assume that's the point

With Anycast I don't think you have the choice of not georeplicating the STEK. And latency is one of their biggest selling points. So you could say they are trying to make the best of a bad situation.

It is absolutely bizarre that the STEK-encrypted session key is not itself sent inside the session encrypted channel.

Re: TLS 1.2 Session Tickets

#17

Post by niftich »

colmmacc wrote: post #9
CaliforniaKarl wrote: post #3

If I understand the article correctly, are all of the issues listed addressed by TLS 1.3?

TLS 1.3 still has problems with STEKs. If you use STEKs with 0-RTT mode, then you lose forward secrecy and that's where the most sensitive data is likely to be: your request, password, credit card number, etc ... 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 is an awful idea anyway; the equivalent of spray-and-pray. Some folks under HTTPbis are working on an Internet Draft on Early Data's (~0-RTT's) ramifications [1] in HTTP.

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

Re: TLS 1.2 Session Tickets

#18

Post by zaroth »

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…

Gives up the property before it begins even. But I completely agree with you. I would go as far to say a connection does not have PFS if you are sending the DH session key encrypted only by a [geographically replicated] static key before the session starts. You are literally destroying the entire purpose of the DH handshake in doing so.

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 :-)"

Re: TLS 1.2 Session Tickets

#19

Post by ramshanker »

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 cleverly tricked into being smooth.

Re: TLS 1.2 Session Tickets

#20

Post by dward »

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...

Post reply on HN