We’re rewarding the question askers & reputations are being recalculated! Read more.
2 added 164 characters in body
source | link

Standard Tor traffic

Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").

For example, my Tor browser randomly chose 62.210.92.11 as the entry point from thea list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.

With bridges

Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).

Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. For exampleE.g., the authors of the paper Detecting and blocking onion router traffic using deep packet inspection madeobserved some observations thatcharacteristics which can be easily deployed as firewall rules, among them:

  • The cipher suites offered by the Tor client are always the same.

  • In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

  • Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could indeedsuccessfully sniff some pseudo domains from a Tor TLS handshake via Tor:

www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

(Even the random domains alone, although you might not be able to filter them reliably, could certainly attract the attention of your local sysadmin.)

Pluggable transports

Pluggable transports are the Tor project's attempt to overcome blocking via DPI-based blocking by providing an API to exchange Tor traffic over differentarbitrary (obscured) protocols which are't detected by a firewall.are harder for firewalls to detect:

Pluggable Transports help you bypass censorship against Tor.

Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.

Standard Tor traffic

Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").

For example, my Tor browser randomly chose 62.210.92.11 as the entry point from the list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.

With bridges

Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).

Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. For example, the authors of the paper Detecting and blocking onion router traffic using deep packet inspection made some observations that can be easily deployed as firewall rules:

  • The cipher suites offered by the Tor client are always the same.

  • In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

  • Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could indeed sniff some pseudo domains from a TLS handshake via Tor:

www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

Pluggable transports

Pluggable transports are the Tor project's attempt to overcome blocking via DPI by providing an API to exchange Tor traffic over different (obscured) protocols which are't detected by a firewall.

Pluggable Transports help you bypass censorship against Tor.

Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.

Standard Tor traffic

Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").

For example, my Tor browser randomly chose 62.210.92.11 as the entry point from a list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.

With bridges

Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).

Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. E.g., the authors of the paper Detecting and blocking onion router traffic using deep packet inspection observed some characteristics which can be easily deployed as firewall rules, among them:

  • The cipher suites offered by the Tor client are always the same.

  • In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

  • Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could successfully sniff some pseudo domains from a Tor TLS handshake:

www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

(Even the random domains alone, although you might not be able to filter them reliably, could certainly attract the attention of your local sysadmin.)

Pluggable transports

Pluggable transports are the Tor project's attempt to overcome DPI-based blocking by providing an API to exchange Tor traffic over arbitrary (obscured) protocols which are harder for firewalls to detect:

Pluggable Transports help you bypass censorship against Tor.

Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.

1
source | link

Standard Tor traffic

Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").

For example, my Tor browser randomly chose 62.210.92.11 as the entry point from the list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.

With bridges

Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).

Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. For example, the authors of the paper Detecting and blocking onion router traffic using deep packet inspection made some observations that can be easily deployed as firewall rules:

  • The cipher suites offered by the Tor client are always the same.

  • In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

  • Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could indeed sniff some pseudo domains from a TLS handshake via Tor:

www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

Pluggable transports

Pluggable transports are the Tor project's attempt to overcome blocking via DPI by providing an API to exchange Tor traffic over different (obscured) protocols which are't detected by a firewall.

Pluggable Transports help you bypass censorship against Tor.

Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.