Opened 7 years ago

Closed 2 years ago

#7145 closed project (implemented)

Evaluate, possibly revise, and then implement ideas for TLS certificate normalization

Reported by: karsten Owned by: nickm
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: SponsorF20130228 tor-client
Cc: nickm, andrea, asn, ioerror, yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (17)

comment:1 Changed 7 years ago by nickm

Keywords: tor-client added

comment:2 Changed 7 years ago by asn

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 and #4550 (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) and tor's security properties (#7189)).

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.

comment:3 Changed 7 years ago by nickm

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

comment:4 Changed 7 years ago by nickm

I think the "easy part of 195" that I want to do for the end-of-feb deliverable is:

  • #4550 -- 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.

Last edited 6 years ago by karsten (previous) (diff)

comment:5 Changed 7 years ago by nickm

oops. Bad formatting there; only the "and" should have been bold.

comment:6 Changed 7 years ago by nickm

Owner: set to nickm
Status: newaccepted

comment:7 Changed 7 years ago by nickm

Keywords: SponsorF20130228 added; SponsorZ removed

comment:8 Changed 7 years ago by nickm

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 still remains, but doesn't look too hard. I'll get that done tomorrow, then put this in needs_review.

comment:9 Changed 7 years ago by nickm

Status: acceptedneeds_review

Branch "bug7145" in my public repository now has an implementation of #4550 ("Allow bridge operators to specify their own link certificates"). It needs documentation, but other than that it should be sound.

comment:10 Changed 6 years ago by remzi2121

Resolution: fixed
Status: needs_reviewclosed

comment:11 Changed 6 years ago by nickm

Resolution: fixed
Status: closedreopened

Looks like this got closed by accident or something? This code still isn't merged.

comment:12 Changed 6 years ago by nickm

Status: reopenedneeds_review

comment:13 Changed 5 years ago by arma

Cc: yawning added

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.)

comment:14 Changed 5 years ago by asn

I think I still stand by comment:2.

PTs are even more deployed now. IMO, there is no need to put extra code in little-t-tor to make it less blockable.
People who want to bypass censorship should use PTs.

comment:15 Changed 5 years ago by andrea

I think I agree with asn's position: PTs solve the problem of censorship evasion for the client->relay case in a clean, modular way that makes this sort of approach obsolete.

comment:16 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: unspecified

Moving these tickets to "tor: unspecified" by the rationale asn and andrea gave in discussion for #7145

comment:17 Changed 2 years ago by nickm

Resolution: implemented
Severity: Normal
Status: needs_reviewclosed

This is as done as it's getting; closing per comments from 2014

Note: See TracTickets for help on using tickets.