Opened 7 years ago

Closed 5 years ago

#7189 closed defect (fixed)

Disabling TLS tickets makes us look unlike firefox

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client tls 023-backport
Cc: nextgens Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #7139, we disabled TLS tickets so that we wouldn't do TLS-ticket based session resumption, to make PFS work right again on our OpenSSL connections.

On the server side, this is probably the right choice for fingerprinting: servers that don't support session resumption also don't support TLS tickets.

But on the client side, it might not be the right choice: firefox advertises support for TLS tickets, I hear. Oops.

This is a nontrivial decision to make. If a client says that it supports TLS tickets, and it is talking to an older Tor server that hasn't disabled them, it will get degraded PFS. But if a client doesn't say it supports TLS tickets, it will apparently be more distinguishable.

We backported #7139 to the 0.2.2 branch; any fix here should get backported too.

Child Tickets

Change History (10)

comment:1 in reply to:  description ; Changed 7 years ago by arma

Replying to nickm:

This is a nontrivial decision to make. If a client says that it supports TLS tickets, and it is talking to an older Tor server that hasn't disabled them, it will get degraded PFS. But if a client doesn't say it supports TLS tickets, it will apparently be more distinguishable.

I'm not too worried about older Tors -- they will become more scarce over time.

We backported #7139 to the 0.2.2 branch; any fix here should get backported too.

0.2.2 still uses the old (Firefox 3) cipher suite. So I'm not convinced this is true.

comment:2 in reply to:  1 Changed 7 years ago by nickm

Replying to arma:

Replying to nickm:

This is a nontrivial decision to make. If a client says that it supports TLS tickets, and it is talking to an older Tor server that hasn't disabled them, it will get degraded PFS. But if a client doesn't say it supports TLS tickets, it will apparently be more distinguishable.

I'm not too worried about older Tors -- they will become more scarce over time.

So the question is, whether they should be allowed to delay clients getting good fast PFS. If we keep tickets out of client connections, then clients who have a new Tor get fast PFS on 100% of their TLS connections right away; and other clients get PFS on U of their TLS connections, where U is the fraction of Tor nodes that have upgraded. Node-to-node TLS has PFS with probability 1-(1-U)2.

But if we put tickets back in Tor servers, then all clients get fast PFS on U of their TLS connections, and node-to-node TLS has PFS with probability U.

One other option to think about is to make this change, but make it later, once more servers have upgraded. We can't make this change in a consensus parameter, though, since that would force us to change our behavior on the fly.

We could probably help the network by having relays turn tickets off unconditionally, so that node-to-node TLS gets fast PFS if either peer is upgraded.

comment:3 Changed 7 years ago by nickm

Status: newneeds_review

I made a branch "bug7189_tentative" in my public repo to implement the (trivial) "let clients advertise session ticket support, and thereby risk getting said session tickets and harming their PFS, but at least they won't be so fingerprintable" fix . I remain unconvinced that it's such a good idea to merge right now; what do others think?

comment:4 Changed 7 years ago by arma

How about putting that patch into 0.2.4, and leaving 0.2.3 alone (to be safer and more fingerprintable)?

comment:5 Changed 7 years ago by nickm

I wouldn't call that crazy. We can put it in 0.2.4, and mark it as backportable to a significantly later 0.2.3 even. Shall I?

comment:6 Changed 7 years ago by arma

i say leave it out of 0.2.3 until somebody dpi's us with it

comment:7 Changed 7 years ago by arma

(and maybe even then)

comment:8 Changed 7 years ago by nickm

Keywords: 023-backport added
Priority: majornormal

Okay, I've put it in 0.2.4 and marked it as backportable.

comment:9 in reply to:  6 Changed 7 years ago by arma

Replying to arma:

i say leave it out of 0.2.3 until somebody dpi's us with it

I think 0.2.4 is sufficiently close to existing that we should abandon a backport here.

comment:10 Changed 5 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final
Resolution: fixed
Status: needs_reviewclosed

Marking a batch of tickets that had been under consideration for 0.2.3 backport as fixed-in-0.2.4. There is no plan for further 0.2.3 releases.

Note: See TracTickets for help on using tickets.