Opened 7 years ago
Closed 18 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: |
Description
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.
Related:
https://trac.torproject.org/projects/tor/wiki/doc/OONI/Tests/d0wser
Child Tickets
Change History (6)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
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>
:
- In the client-side
C
, OONI should fire up Tor and capture its (handshake) traffic (with libpcap). - If Tor was not blocked, we are done already.
- 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]
- 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
Cc: | isis@… added |
---|
comment:4 Changed 7 years ago by
Keywords: | ooni_wishlist added |
---|
comment:5 Changed 2 years ago by
Severity: | → Normal |
---|
Set all open tickets without a severity to "Normal"
comment:6 Changed 18 months ago by
Keywords: | archived-closed-2018-07-04 added |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Close all tickets in archived components
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.