aviduser

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by aviduser

  1. Reposted from the general suggestion forum. I have done research work on this and hope the following information will be helpful to others. The current GFW block on resilio and btsync: 1. GFW does not block the initial configuration load (to get a list of trackers for example). DNS resolution and download will all work. 2. GFW does block the subsequent connections to the trackers. This is done at IP packet inspection level. This blocking was initially started in some cities but eventually spread to all. Connections to the trackers are cut-off prematurely (EOF received). The current workaround (See the limitations) that proven to be working. 1. You can setup predefined hosts in resilio for all shares. In BTSync, you can only setup predefined hosts for each share individually - which is a chore. This method works as the deep packet inspection currently only targets the trackers, not individual connections between btsync/resilio servers. 2. To be practical, you will need to setup a dynamic dns name (DDNS) for each btsync server and use a fixed port number (e.g. host1.blah.com:4444, host2.xyz.com:4444, host3.uvw.com:4444). Because servers are usually behind home routers, NAT is used. Your router must be able to turn on NAT-PMP so that the port 4444 will be opened on the router to your server. uPNP would also work though NAT-PMP is more secure. Limitations: 1. If deep inspection targets server to server direct connections, the above workaround will likely to fail. The server-to-server protocol probably contains sufficient unique string for inspection and targeting. 2. Use the next alternative. An alternative to BTsync/Resilio would work and resist deep packet inspections - syncthing. (Sorry, resilio) Syncthing is an open source project and it was a little shaky a 2-3 years back but now it's quite stable and mature. Similar to BTSync/resilio, Syncthing also has global discovery servers for servers to discover each other. They are subject to the same blocking in the future. However, Syncthing also has predefined hosts method simliar to BTSync. This direct connection method is resistant to DPI. Syncthing's protocol is strictly TLS 1.2 with no special customization identifiable before the TLS handshake completes. This makes it very resistant to future deep packet inspection. To be more specific, when 2 servers connect to each other, they will always complete the TLS handshake first. Before the handshake is complete, there is nothing identifiable in the communication than any regular HTTPS traffic. After the handshake completes, when communication is secure, the servers will check each other certificate to determine if they are configured to talk to each other. They drop if they are not configured to trust each other. For this reason, syncthing direct server connection will resist future DPI. - Good luck everyone! P.S. I should add that using socks proxy is not a universal solution. It's not only complicated to setup for a lay user, but the socks proxy itself needs to be in the region unblocked (such as overseas). It also must be a private socks proxy than a public one (or it will be blocked too).
  2. I have done research work on this and hope the following information will be helpful to others. The current GFW block on resilio and btsync: 1. GFW does not block the initial configuration load (to get a list of trackers for example). DNS resolution and download will all work. 2. GFW does block the subsequent connections to the trackers. This is done at IP packet inspection level. This blocking was initially started in some cities but eventually spread to all. Connections to the trackers are cut-off prematurely (EOF received). The current workaround (See the limitations) that proven to be working. 1. You can setup predefined hosts in resilio for all shares. In BTSync, you can only setup predefined hosts for each share individually - which is a chore. This method works as the deep packet inspection currently only targets the trackers, not individual connections between btsync/resilio servers. 2. To be practical, you will need to setup a dynamic dns name (DDNS) for each btsync server and use a fixed port number (e.g. host1.blah.com:4444, host2.xyz.com:4444, host3.uvw.com:4444). Because servers are usually behind home routers, NAT is used. Your router must be able to turn on NAT-PMP so that the port 4444 will be opened on the router to your server. uPNP would also work thought NAT-PMP is more secure. Limitations: 1. If deep inspection targets server to server direct connections, the above workaround will likely to fail. The server-to-server protocol probably contains sufficient unique string for inspection and targeting. 2. Use the next alternative. An alternative to BTsync/Resilio would work and resist deep packet inspections - syncthing. (Sorry, resilio) Syncthing is an open source project and it was a little shaky a 2-3 years back but now it's quite stable and mature. Similar to BTSync/resilio, Syncthing also has global discovery servers for servers to discover each other. They are subject to the same blocking in the future. However, Syncthing also has predefined hosts method simliar to BTSync. This direct connection method is resistant to DPI. Syncthing's protocol is strictly TLS 1.2 with no special customization identifiable before the TLS handshake completes. This makes it very resistant to future deep packet inspection. To be more specific, when 2 servers connect to each other, they will always complete the TLS handshake first. Before the handshake is complete, there is nothing identifiable in the communication than any regular HTTPS traffic. After the handshake completes, when communication is secure, the servers will check each other certificate to determine if they are configured to talk to each other. They drop if they are not configured to trust each other. For this reason, syncthing direct server connection will resist future DPI. - Good luck everyone! P.S. I should add that using socks proxy is not a universal solution. It's not only complicated to setup for a lay user, but the socks proxy itself needs to be in the region unblocked (such as overseas). It also must be a private socks proxy than a public one (or it will be blocked too).