On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex <[email protected]> wrote: > 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.
I assume good faith on your part; please do the favor of assuming good faith on mine. > 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. Indeed, I never said this was a "severe" issue, or that it was the only issue you need to solve to solve fingerprinting. I said: "This provides a fingerprint that can track users in spite of other attempts to make them untrackable." I know that reading perpass, one expects proposals to fundamentally transform the Internet to make it more secure. This is not such a fundamental transformation. This is a little simple change to fix a little simple little problem. Of such simple little problems, client linkability is made. > 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. That's all true; disabling gmt_unix_time is by no means sufficient to make multiple TLS clients look the same on the wire, or to prevent an observer distinguishing TLS instances. In Tor's case, we mitigate this by disabling some TLS features, specifying required values for others, rotating some identifiers more frequently than most implementations, and shipping all of our clients with the same crypto libraries. Most of the fingerprinting issues in TLS can be ameliorated, for a single application, by defining a profile that all of that application's users should share. My issue here right now that, even *after* taking all these precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC doesn't make it optional. Come heck or high water, Tor is going to stop sending gmt_unix_time unless we find a really excellent reason to send it. We'd like to replace it with the best alternative we can. I sent all the alternatives I could think of, because: 1) I would like future versions of the TLS RFC to not require gmt_unix_time. 2) I would like to know whether there's a truly legit reason to send gmt_unx_time. 3) I would like to know the best thing to do instead of gmt_unix_time. (The IP address issue is important too, but not overriding here. The issue here is that even after a client has changed its IP addresses either through moving around the network or going behind a NAT or VPN or by using an IP anonymization service, this fingerprint remains.) -- Nick _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
