Opened 7 years ago

Closed 7 years ago

#7139 closed defect (fixed)

Tor involuntarily sets TLS session tickets

Reported by: nextgens Owned by:
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay ssl tls security pfs
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is bad for at least two reasons:

1) performance: It increases the size (~160bytes) of the ChangeCipherSpec message during the handshake; it also makes the server encrypt and hmac the ticket

2) security: It has implications regarding the PFS interval (no immediate security concern here as the server certificates are ephemeral; MAX_SSL_KEY_LIFETIME_INTERNAL = 2h atm) and exposes more attack surface than strictly necessary (Tor doesn't use the tickets in any case: that's why it disables the session-cache)

To disable session-tickets altogether (TLS1+ feature), one should use:
SSL_CTX_set_options(... , ...|SSL_OP_NO_TICKET)

Child Tickets

Change History (12)

comment:1 Changed 7 years ago by nickm

Keywords: tor-relay added
Milestone: Tor: 0.2.2.x-final
Priority: normalmajor

I think this should go in even 0.2.2.

comment:2 Changed 7 years ago by nickm

Cc: arma added

comment:3 Changed 7 years ago by nickm

Status: newneeds_review

Possible patch (against maint-0.2.2) at bug7139.

comment:4 Changed 7 years ago by arma

On the "do we want to force every debian user of tor to freak out and rush to upgrade" theory, it looks like we should put this into 0.2.3 and not 0.2.2?

Or said another way, what's the reasoning for putting it in 0.2.2 other than "it's a bug in 0.2.2 too"?

comment:5 Changed 7 years ago by nextgens

Let me rephrase the above as it might not have been clear enough:

If you assume that the key material used to encrypt the tickets is swapped out to disk, you have a security problem whereby you've lost PFS. A potential attacker in possession of both the ciphertext AND the leaked key material (network traffic capture + swapfile) can recover the plaintext by decrypting the session ticket.

Openssl will generate ephemeral, random, per session keys to encrypt the ticket unless tlsext_ticket_key_cb is set (Tor doesn't set it) and stores them in the session cache (that Tor explicitly disables). The code related to this is in ssl3_send_newsession_ticket... Bottom line is, the keys are in memory and might end up on disk...

comment:6 Changed 7 years ago by nextgens

So, my point number 2 in the original report is incorrect and should read:

2) security: It has implications regarding PFS (the key material encrypting the ticket is ephemeral but might be swapped out to disk) and exposes more attack surface than strictly necessary (Tor doesn't use the tickets in any case)

The PFS interval is not linked to MAX_SSL_KEY_LIFETIME_INTERNAL at all.

comment:7 Changed 7 years ago by nickm

Hm. So, I buy the "more attack surface than necessary" argument as a reason to put it in 0.2.3 and later, but I don't think the swapping argument necessarily holds water.

If we're worried about the key material getting used to encrypt tickets getting swapped out to disk, we also need to worry about the session key material getting swapped out, surely. If you're swapping and your swap isn't encrypted, I don't think you get PFS guarantees.

I could be missing something crucial there--am I?

comment:8 Changed 7 years ago by nextgens

You're not. PFS can't be achieved if you swap to disk... regardless of whether you use TLS session tickets or not.

Now: another amendment of what I wrote above: for the record: OpenSSL does stores the ticket's encryption key in SSL_CTX, which in Tor's case is renewed every MAX_SSL_KEY_LIFETIME_INTERNAL... So that's your current PFS interval... and my initial report was accurately describing what is happening.

The reasons to disable TLS session tickets in Tor's case are:

  • Not required / used at all (waste of CPU cycles and bandwidth)
  • Less attack surface exposed (hardening)
  • The PFS interval is MAX_SSL_KEY_LIFETIME_INTERNAL as you use 'ephemeral certificates' (keep in mind if you plan on increasing it)
  • The cipher negotiated is irrelevant ... No one will attack DHE-RSA-AES256-SHA if the ticket is encrypted using AES-128... so that's yetAnotherWaste of CPU cycles

There is no direct security implication warranting an emergency release IMHO.

comment:9 Changed 7 years ago by arma

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

comment:10 Changed 7 years ago by nickm

I pushed a new bug7139_023 with the same code and a slightly different commit message and changes file.

I think this is backportable to 0.2.2, since a long-lived connection can keep a SSL_CTX alive.

comment:11 Changed 7 years ago by arma

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final

comment:12 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Discussed with arma: We're putting this in the next 0.2.2 if there is one and it doesn't break later releases horribly. So merging to 0.2.2 and later, but not pushing an 0.2.2 for this.

Note: See TracTickets for help on using tickets.