Evaluate, possibly revise, and then implement ideas for TLS certificate normalization
Proposal 195 specifies ideas for TLS certificate normalization for Tor 0.2.4.x. We should evaluate this proposal, come up with new ideas for TLS normalization as appropriate, and implement the ones that represent a real improvement in Tor.
Activity
changed milestone to %Tor: unspecified
Opinion piece:
On the "Evaluate, possibly revise" phase, how much of proposal 195 should we actually care to do?
Some parts of proposal 195 are easy-ish; like using better CNs or changing the certificate lifetime. Other parts of proposal 195 are not trivial to implement and change lots of core tor code, like #4549 (moved) and #4550 (moved) (see the ticket discussion to see why link-protocol code needs to be changed).
I like how PTs moves the circumvention rat race to another (more flexible) layer, and nowadays that PTs are kiiiiind-of deployed, I don't like changing core parts of little-t-tor for circumvention purposes (like the link-protocols (#4549 (moved)) and tor's security properties (#7189 (moved))).
As a matter of fact, in a future where PTs are widely deployed and all users know that they have to use PTs to circumvent censorship, I would enjoy little-t-tor having no circumvention capabilities whatsoever and solely relying on PTs to be undetectable. That is, I would like complete layer separation: little-t-tor gives me security/anonymity and PTs give me censorship circumvention.
WRT 195, I don't have specific rules of thumb on which changes we should do, but IMO we should only change little-t-tor for circumvention purposes when:
- It will unblock vanilla Tor in large jurisdictions. and
- The change is easy to implement and reason about.
In other cases, I think that the manpower required to implement parts of 195 is better invested in doing other little-t-tor tasks, or in helping with further deployment of PTs.
I think the "easy part of 195" that I want to do for the end-of-feb deliverable is:
- #4550 (moved) -- allow user-specified link certificates. Once that's done, it provides a way for bridge operators to avoid fingerprinting based on validity times and intervals and to avoid fingerprinting based on DN strings.
Additionally, I want to let clients set their own cipher lists, so long as they include at least RSA-AES-128-EDH or RSA-AES-256-EDH.
I believe I can get a branch coded here tonight and tomorrow.
-
Additionally, I want to let clients set their own cipher lists, so long as they include at least RSA-AES-128-EDH or RSA-AES-256-EDH.
I did this, plus some necessary refactoring, in branch "bug7145" in my public repo. #4550 (moved) still remains, but doesn't look too hard. I'll get that done tomorrow, then put this in needs_review.
-
Branch "bug7145" in my public repository now has an implementation of #4550 (moved) ("Allow bridge operators to specify their own link certificates"). It needs documentation, but other than that it should be sound.
Trac:
Status: accepted to needs_review 
This would be a good question to ask asn et al from the PT team: how useful would this be to let people experiment with?
As we wait the patch rots more, so if we actually want the feature, we should try to get it in sooner rather than later. (But if we don't want the feature, getting the patch in and then later having bugs reported against it and having the bugs sit about for months isn't so hot either.)
Trac:
Cc: nickm, andrea, asn, ioerror to nickm, andrea, asn, ioerror, yawning-
Moving these tickets to "tor: unspecified" by the rationale asn and andrea gave in discussion for #7145 (moved)
Trac:
Milestone: Tor: 0.2.5.x-final to Tor: unspecified
