[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #6349 [Ooni]: Make OONI SSL fingerprint bisecting plugin

#6349: Make OONI SSL fingerprint bisecting plugin
--------------------+-------------------------------------------------------
 Reporter:  asn     |          Owner:  hellais
     Type:  defect  |         Status:  new    
 Priority:  normal  |      Milestone:         
Component:  Ooni    |        Version:         
 Keywords:          |         Parent:         
   Points:          |   Actualpoints:         
--------------------+-------------------------------------------------------

Comment(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]
 5. 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)?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6349#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs