Opened 7 years ago

Closed 12 months ago

#6349 closed defect (wontfix)

Make OONI SSL fingerprint bisecting plugin

Reported by: asn Owned by: hellais
Priority: Medium Milestone:
Component: Archived/Ooni Version:
Severity: Normal Keywords: ooni_wishlist, archived-closed-2018-07-04
Cc: phw, isis@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


OONI needs a plugin that can be ran by people in countries were Tor is censored by DPI, and it will output the (SSL) fingerprint used by the DPI box.


Child Tickets

Change History (6)

comment:1 Changed 7 years ago by asn

To make such a plugin properly, it will probably require a client-server architecture where both sides would mutate the TLS handshake in turns to brute-force the fingerprints.

At the same time, an off-band communication channel between the client and the server might be needed so that they can signal to each other which packets get censored and what the next bisection step should be.

comment:2 Changed 7 years ago by asn

Some thoughts: Let's say that we have an OONI client C in <censored country> and an OONI server S anywhere else in the world. To RE the DPI fingerprint of <censored country>:

  1. In the client-side C, OONI should fire up Tor and capture its (handshake) traffic (with libpcap).
  2. If Tor was not blocked, we are done already.
  3. If Tor was blocked, feed the pcap to OONI. OONI should output a tuple of messages for each side which signify the messages that each side should send or expect to receive [0].

4a. In the client-side C, sequentially do n mutated handshakes, where n is the total number of bytes of messages. [1]
4b. Foreach handshake, figure out if it was censored. If yes, the currently mutated handshake byte was not part of the DPI fingerprint. If it was censored, we found a byte of the fingerprint and we add it to our list. [2]

  1. Output the list of fingerprints.

By mutated handshake we mean a full TLS handshake where one of its bytes will be mutated (increased by one).

By figure out if it was censored we mean detecting a network behavior that signifies that a handshake was blocked. That might be absense of ACK, a TCP RST, a TCP retransmission, etc. The figure out part is not that easy since each DPI box might have different ways of blocking (for example a DPI box might not block the current connection, but might block any subsequent connections).

[0]: This tuple might look like this (example for the client-side):
(<ClientHello data>, <Wait for X bytes>, <ClientKeyExchange, ChangeCipherSpec, ClientHelloDone data>, <Wait for Y bytes> ...)
[1]: What happens if the block is permanent? Do we have to use a different bridge IP or TCP port for each mutation?
[2]: What happens if the handshake triggers active probing instead of instant blocking? Do we need n different bridge IPs (or TCP ports)?

comment:3 Changed 7 years ago by isis

Cc: isis@… added

comment:4 Changed 7 years ago by hellais

Keywords: ooni_wishlist added

comment:5 Changed 19 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:6 Changed 12 months ago by teor

Keywords: archived-closed-2018-07-04 added
Resolution: wontfix
Status: newclosed

Close all tickets in archived components

Note: See TracTickets for help on using tickets.