Opened 6 years ago

Closed 6 years ago

#9499 closed defect (fixed)

BridgeDB should hand out identity fingerprints

Reported by: mikeperry Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: path-bias, bridgedb-dist, pt, vidalia
Cc: isis, mikeperry, phw, asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Once we deprecate Vidalia fully and switch to Tor Launcher, nothing should be in the way of handing out identity hex keys for bridges. Well, nothing except #9445 (which if it comes down to it, I can fix quickly myself).

It is important to hand out these fingerprints because it mitigates path bias/route capture attacks. Without the identity fingerprint, a firewall could potentially MITM the bridge connection for purposes of unwrapping TLS, in order to see the Tor cell headers and bitstomp/tag cells to control circuit destinations and deanonymize users. We have detectors for these attacks in place, but they can't be enforced yet because of the highly variable rate of CPU overload/circuit failure on the network. Other solutions to bitstomping (like wide-block ciphers) will also mitigate these attacks, but they are a long ways off.

With the identity fingerprint, the TLS links will be authenticated (our TLS connections use the identity key to sign a short-lived TLS link key).

Child Tickets

TicketStatusOwnerSummaryComponent
#10559closedisisBridgeDB writes `keyid=` before fingerprintsCircumvention/BridgeDB

Change History (6)

comment:1 Changed 6 years ago by isis

Cc: mikeperry phw asn added
Keywords: bridgedb-dist pt vidalia added
Status: newneeds_information

I can enable this easily. There are actually several problems, as far as I can tell:

  1. Enabling the handing out of bridge fingerprints breaks Vidalia. See #5851.
  2. Using bridge fingerprints with PT bridges which use the new argslist feature to pass shared secrets is likely messing up both tor and Vidalia. This needs more testing.

For (2) above, I tried the following lines for the scramblesuit bridge that I set up for testing purposes, pasting them directly into my torrc, using ARM as a controller (both on the server and client to watch the connection attempts):

bridge scramblesuit 69.164.208.188:6666 keyid=AC19189ADFAEA697CB7C02AC141CC60997922B6F,password=93edd2b39b06115b38778e5447be6171d34cf63cc0e083db91fca9ce7fe920fa
bridge scramblesuit 69.164.208.188:6666 AC19189ADFAEA697CB7C02AC141CC60997922B6F password=93edd2b39b06115b38778e5447be6171d34cf63cc0e083db91fca9ce7fe920fa

which spewed errors in various places, including:

  1. scramblesuit thinking that the 'keyid=' was the scramblesuit password, and telling me that I had an invalid password.
  2. scramblesuit getting mad at me and saying that there were 'non base-64 characters in the password'.
  3. tor saying that 'the fingerprint for bridge XXXXXX is the wrong size'.

The last of which should only be a problem for PT bridges whose methods need to use the argslist. I do not know yet if the error is in little-t tor, or elsewhere.

comment:2 in reply to:  1 Changed 6 years ago by phw

Replying to isis:

  1. scramblesuit thinking that the 'keyid=' was the scramblesuit password, and telling me that I had an invalid password.
  2. scramblesuit getting mad at me and saying that there were 'non base-64 characters in the password'.

At this point, I'm assuming that the arguments are formatted correctly. I will add some basic sanity checking and reasonable error messages. Thanks for testing this!

comment:3 in reply to:  1 ; Changed 6 years ago by asn

Replying to isis:

I can enable this easily. There are actually several problems, as far as I can tell:

  1. Enabling the handing out of bridge fingerprints breaks Vidalia. See #5851.
  2. Using bridge fingerprints with PT bridges which use the new argslist feature to pass shared secrets is likely messing up both tor and Vidalia. This needs more testing.

For (2) above, I tried the following lines for the scramblesuit bridge that I set up for testing purposes, pasting them directly into my torrc, using ARM as a controller (both on the server and client to watch the connection attempts):

bridge scramblesuit 69.164.208.188:6666 keyid=AC19189ADFAEA697CB7C02AC141CC60997922B6F,password=93edd2b39b06115b38778e5447be6171d34cf63cc0e083db91fca9ce7fe920fa
bridge scramblesuit 69.164.208.188:6666 AC19189ADFAEA697CB7C02AC141CC60997922B6F password=93edd2b39b06115b38778e5447be6171d34cf63cc0e083db91fca9ce7fe920fa

The second form is correct. The first is wrong since the keyid key is unsupported.

BTW, check out Tor's test_config_parse_bridge_line() unit test. It seems to me that the second form should work as far as little-t-tor is concerned.

comment:4 in reply to:  3 Changed 6 years ago by isis

Replying to asn:

The second form is correct. The first is wrong since the keyid key is unsupported.


It seems the keyid= field is added somewhere in BridgeDB, at least for PT bridges it is. I just created #10559, but it should be a simple fix.

BTW, check out Tor's test_config_parse_bridge_line() unit test. It seems to me that the second form should work as far as little-t-tor is concerned.


Thanks for pointing this out!

comment:5 Changed 6 years ago by isis

Owner: set to isis
Status: needs_informationaccepted

BridgeDB now hands out bridge fingerprints for both the HTTPS and email distributors.

comment:6 Changed 6 years ago by isis

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.