TLS 1.2 Session Tickets

#1

Post by gtank » Thu, Sep 28, 2017, 4:28 PM UTC

TLS 1.2 Session Tickets
blog.filippo.io

Re: TLS 1.2 Session Tickets

#2

Post by jgrahamc » Thu, Sep 28, 2017, 4:50 PM UTC

Re: TLS 1.2 Session Tickets

#3

Post by CaliforniaKarl » Thu, Sep 28, 2017, 5:02 PM UTC

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

Re: TLS 1.2 Session Tickets

#4

Post by tony101 » Thu, Sep 28, 2017, 5:15 PM UTC

CaliforniaKarl wrote: post #3

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

I believe you're correct.

Re: TLS 1.2 Session Tickets

#5

Post by tony101 » Thu, Sep 28, 2017, 5:20 PM UTC

> 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 up this property as soon as it begins.

Re: TLS 1.2 Session Tickets

#6

Post by CaliforniaKarl » Thu, Sep 28, 2017, 5:28 PM UTC

tony101 wrote: post #4

CaliforniaKarl wrote: post #3

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

I believe you're correct.

OK, cool! In that case, I wish the article title was different, to reflect that the issues detailed in the article have all been fixed in TLS 1.3. I think it wasn't until the end of the first issue that "fixed in TLS 1.3" was mentioned.

Re: TLS 1.2 Session Tickets

#7

Post by FiloSottile » Thu, Sep 28, 2017, 5:35 PM UTC

CaliforniaKarl wrote: post #3

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

Strongly mitigated if not entirely fixed, but TLS 1.3 deployment is stalled on awful middleboxes breaking connections they have no business in, and TLS 1.2 is not nearly broken enough to see a significant exodus.

So this is what we are stuck with for the time being.

Re: TLS 1.2 Session Tickets

#8

Post by sdevlin » Thu, Sep 28, 2017, 5:37 PM UTC

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?

Re: TLS 1.2 Session Tickets

#9

Post by colmmacc » Thu, Sep 28, 2017, 5:44 PM UTC

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.

Re: TLS 1.2 Session Tickets

#10

Post by xenophonf » Thu, Sep 28, 2017, 5:49 PM UTC

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