Opened 8 years ago

Closed 2 years ago

#4390 closed defect (duplicate)

The rotation of the TLS context can act as a fingerprint for bridges

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: fingerprint, blocking, maybe-proposal, tor-bridge
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Censors can monitor the traffic of a suspected bridge every MAX_SSL_KEY_LIFETIME_INTERNAL and see if the TLS certificate has changed.

Normal SSL services don't change certificates every 2 hours.

Maybe we should consider increasing MAX_SSL_KEY_LIFETIME_INTERNAL.
Maybe we should consider implementing and documenting it as part of prop179 (#3972).

Child Tickets

Change History (15)

comment:1 Changed 8 years ago by arma

Increasing the link cert's lifetime would also help the mirror image of this attack, which is "How come that cert was born less than 2 hours ago? That never happens unless it's Tor."

comment:2 Changed 8 years ago by asn

This will probably also need a proposal to figure out the new cert lifetime, where the SSL certificates will be stored on disk, etc.

comment:3 Changed 8 years ago by nickm

This could dovetail nicely with other certificate changes proposed in prop179. If we want to allow non-Tor-generated certs to be read from disk, we can also allow Tor to store its certificates to disk and keep them there for a long while.

comment:4 Changed 8 years ago by asn

This is also necessary for:
https://lists.torproject.org/pipermail/tor-dev/2011-November/003061.html

Do you people have any opinions on the new validity duration of the certificates?

The scheme described in the above link, would enjoy long-term certificates, because every time a certificate expires the bridge operator has to manually re-propagate its fingerprint.

Do you have any ideas on a good validity duration? Or do you have any ideas on a bad validity duration?

Rotating certificates and keys is good practice, but in the case of SSL the Ephemeral DH ciphers guarantee PFS. In any case, if a relay gets rooted, They already get the identity key which doesn't have an expiration date.

comment:5 Changed 8 years ago by nickm

Keywords: fingerprint blocking added
Milestone: Tor: 0.2.3.x-final

This may get fixed (at least partially) with other prop 179 stuff. If not, we can remove it from this milestone.

comment:6 Changed 8 years ago by nickm

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

comment:7 Changed 7 years ago by nickm

Keywords: maybe-proposal added

comment:8 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:9 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:11 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:12 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:14 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 2 years ago by nickm

Resolution: duplicate
Severity: Normal
Status: newclosed

I believe that PTs render this obsolete.

Note: See TracTickets for help on using tickets.