Nick Mathewson wrote: > ==== > SYNOPSIS: > > In TLS as currently specified, clients and servers each send their > current view of "the time" in the clear as part of their handshake. > This provides a fingerprint that can track users in spite of other > attempts to make them untrackable. I propose several ways to stop > doing sending this cleartext timestamp; some trivial and some more > complex.
I would really appreciate a different approach to the underlying issue, and less throwing of smoke grenades here. If you're worried about being slightly "distinguishable" from some other clients, then there are a lot more reliable identifiers available in the average TLS handshake, so claiming that sending the actual local time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting issue and sending random will solve the fingerprinting issue, is bordering on lame for >99% of the clients. Most of the time, repeated requests of the same TLS client can be identified by the network connection having the same client IP address, the TLS session proposed for resumption in ClientHello.session_id or maybe someone still using TLS session tickets (rfc5077). So rather than pointing to ClientHello.Random.gmt_unix_time as a and claiming there would be a simple fix, one will likely have to create and go through a long list of issues to determine which features facilitate fingerprinting and tracking (cipher suites and many TLS extensions (TLS caching extension, signature algorithms, Next protocol negotiation, supported elliptic curves, etc.) may all help in distinguishing clients, and would also have to be taken care of. -Martin _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
