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

Re: [tor-bugs] #7141 [Censorship analysis]: How is Pars Online blocking Tor?



#7141: How is Pars Online blocking Tor?
------------------------------------------+---------------------------------
 Reporter:  phw                           |          Owner:  phw
     Type:  task                          |         Status:  new
 Priority:  normal                        |      Milestone:     
Component:  Censorship analysis           |        Version:     
 Keywords:  dpi, censorship, block, iran  |         Parent:     
   Points:                                |   Actualpoints:     
------------------------------------------+---------------------------------

Comment(by phw):

 A user was able to find out more. The following is my summary of what we
 were told on IRC. However, keep in mind that the following was indeed
 tested but should '''not''' be considered as fact at this point.

 It still looks like the `server_name` extension (SNI) is crucial. Other
 fingerprints could not be found so far. The user tested this theory by
 adding a bogus hostname to /etc/hosts pointing to an existing web server
 (for example Google's). Apparently, the TLS handshake belonging to the
 bogus host connection was blocked for all major browsers (Opera, IE9,
 Chrome, Firefox16). A middle box might have tried to resolve the bogus
 hostname which failed - resulting in the block.

 Now regarding the concrete implementation - once again, this is merely a
 hypothesis. Some sort of DNS cache might be used by the middle boxes. It
 would make sense since it's expensive to run DNS queries for every
 (suspicious) TLS handshake. The user reported that even "benign" non-Tor
 handshakes sometimes did not work. But they '''did''' work later. One
 explanation would be that the middle boxes had a cache miss and had to
 populate the cache with the new DNS record.

 Furthermore, the user could connect to a (previously blocked?) relay by
 creating a dyndns record and pointing it to the relay's IP address. The
 first handshake failed (cache miss?) but the next day it succeeded.

 Also, the user thinks that there might be whitelisted IP address blocks
 where middle boxes do not mess with handshakes.

 I set up a private bridge running a modified version of
 [https://gitweb.torproject.org/brdgrd.git brdgrd]. It should make the Tor
 client split the `server_name` extension in two TCP segments. The bridge
 worked for the user but this is just anecdotal evidence. Please contact me
 if you want the bridge descriptor.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7141#comment:3>
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