Opened 5 years ago

Last modified 2 months ago

#11101 assigned enhancement

Bridges should report implementation versions of their pluggable transports

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: bridgedb, needs-proposal, needs-spec, pt, tor-bridge, tor-pt, 032-unreached
Cc: asn, phw, yawning, isis Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor:

Description

Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones?

One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it.

Are there better options than this one?

Child Tickets

Change History (18)

comment:1 Changed 5 years ago by sysrqb

(Not having followed the scramblesuit review, this is a general answer)

For advertising to a third-party which version of a PT the bridge runs the extra-info document will be the place to do it. The pt spec places some restrictions on the name:

  Method names MUST be C identifiers. That is, method names must begin
  with a letter or underscore and the rest of the characters can be
  letters, numbers or underscores. No length limit is imposed. The
  relevant regular expression is: "[a-zA-Z_][a-zA-Z0-9_]*".

so if we amend dir-spec to specify that the transport line in the extra-info document can include the version by appending a -version_number suffix to the name, then this can be retrieved and removed by other players (e.g. bridgedb, metrics, etc), e.g. obfsproxy-0.2.6. I'm interested if there's a better way than this, though.

The only catch (that I know of) is that the PT will need to tell tor its version number, and I'm not aware of an available mechanism for this (but maybe I missed it).

comment:2 in reply to:  1 Changed 5 years ago by asn

Replying to sysrqb:

(Not having followed the scramblesuit review, this is a general answer)

For advertising to a third-party which version of a PT the bridge runs the extra-info document will be the place to do it. The pt spec places some restrictions on the name:

  Method names MUST be C identifiers. That is, method names must begin
  with a letter or underscore and the rest of the characters can be
  letters, numbers or underscores. No length limit is imposed. The
  relevant regular expression is: "[a-zA-Z_][a-zA-Z0-9_]*".

so if we amend dir-spec to specify that the transport line in the extra-info document can include the version by appending a -version_number suffix to the name, then this can be retrieved and removed by other players (e.g. bridgedb, metrics, etc), e.g. obfsproxy-0.2.6. I'm interested if there's a better way than this, though.

Another kludgy way of doing this would be to define a special internal k=v parameter (call it _version or something) that gets passed as part of the transport line arglist to BridgeDB, but BridgeDB doesn't give it to clients. The _version parameter would state the version of the PT.

In both cases, BridgeDB has to do processing before passing bridges to the clients. For example, in the obfs3-0.2.6 case, it would have to strip -0.2.6 out, and only pass obfs3

The only catch (that I know of) is that the PT will need to tell tor its version number, and I'm not aware of an available mechanism for this (but maybe I missed it).

Indeed there is not. It can be done through the SMETHOD line.

This is not a terrible amount of work, and it's probably worth it. Better less-kludgy solutions are welcome.

comment:3 Changed 5 years ago by isis

Cc: isis added
Keywords: bridgedb added

I have a slight preference for doing the transport-line arglist _version=x.x.x argument, rather than actually changing the identifiers for PT types.

comment:4 Changed 5 years ago by nickm

Keywords: needs-proposal added
Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:5 Changed 4 years ago by isis

Keywords: needs-spec pt 028-triage added
Milestone: Tor: 0.2.???Tor: 0.2.8.x-final
Owner: set to isis
Points: medium
Status: newassigned

Happy to take this one. We'll need to remember to update pt-spec.txt (and/or pt-spec-v2.txt) if we start having "internal" PT args.

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Status: assignednew

Turn most 0.2.8 "assigned" tickets with no owner into "new" tickets for 0.2.9. Disagree? Find somebody who can do it (maybe you?) and get them to take it on for 0.2.8. :)

comment:7 Changed 3 years ago by nickm

Sponsor: SponsorS-can

Tagging these bridge- and PT- items as S-can.

comment:8 Changed 3 years ago by nickm

Keywords: tor-bridge tor-pt added

comment:9 Changed 3 years ago by isabela

Points: medium3

comment:10 Changed 3 years ago by isis

Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

Defer some of my 029 tickets to 030

comment:11 Changed 3 years ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Triaged out on December 2016 from 030 to 031.

comment:12 Changed 2 years ago by nickm

Sponsor: SponsorS-can

Clear sponsorS and sponsorU from open tickets in 0.3.1

comment:13 Changed 2 years ago by isis

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

Deferring to 0.3.2

comment:14 Changed 2 years ago by nickm

Keywords: triage-out-030-201612 removed

comment:15 Changed 2 years ago by nickm

Keywords: 028-triage removed

comment:16 Changed 2 years ago by nickm

Keywords: 032-unreached added
Milestone: Tor: 0.3.2.x-finalTor: unspecified

Mark a large number of tickets that I do not think we will do for 0.3.2.

comment:17 Changed 21 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:18 Changed 2 months ago by gaba

Owner: isis deleted
Status: newassigned
Note: See TracTickets for help on using tickets.