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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7141: How is Iran 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):

 Independent of the above report, which might not even be targeting Tor,
 there is another filtering technique which seems to affect parts of Iran.
 It looks like DPI boxes fingerprint information in the TLS client key
 exchange which is sent after the TLS server hello. The client key exchange
 never makes it to the bridge. It is silently dropped somewhere along the
 path. The following flow diagram illustrates this behavior:

 {{{
 |Time     | .ir Client                       Relay |
 |         |                                        |
 |0.060    |         12345 > 443 [SYN]              |TCP: 12345 > 443 [SYN]
 |         |(12345)   ------------------>  (443)    |
 |0.322    |         443 > 12345 [SYN, ACK]         |TCP: 443 > 12345 [SYN,
 ACK]
 |         |(12345)   <------------------  (443)    |
 |0.322    |         12345 > 443 [ACK]              |TCP: 12345 > 443 [ACK]
 |         |(12345)   ------------------>  (443)    |
 |0.374    |         Client Hello                   |TLSv1: Client Hello
 |         |(12345)   ------------------>  (443)    |
 |0.660    |         Server Hello, Certi            |TLSv1: Server Hello,
 Certificate, Server Key Exchange, Server Hello Done
 |         |(12345)   <------------------  (443)    |
 |0.676    |         Client Key Exchange            |TLSv1: Client Key
 Exchange, Change Cipher Spec, Encrypted Handshake Message
 |         |(12345)   ------------------>  (443)    |
 |3.201    |         [TCP Retransmission            |TLSv1: [TCP
 Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted
 Handshake Message
 |         |(12345)   ------------------>  (443)    |
 |8.357    |         [TCP Retransmission            |TLSv1: [TCP
 Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted
 Handshake Message
 |         |(12345)   ------------------>  (443)    |
 |18.746   |         [TCP Retransmission            |TLSv1: [TCP
 Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted
 Handshake Message
 |         |(12345)   ------------------>  (443)    |
 |29.135   |         [TCP Retransmission            |TLSv1: [TCP
 Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted
 Handshake Message
 |         |(12345)   ------------------>  (443)    |

 }}}
 In a new packet dump, we have even seen obviously spoofed RST segments
 being sent '''in addition''' to the silent packet drop. After the
 fingerprint is detected, several RST segments are sent to both, the client
 and the bridge. However, the RST segments are not well-formed and as a
 result not accepted by the client's and the bridge's TCP stack. Perhaps
 somebody is experimenting with out-of-band boxes.

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