search

wangyu- / udp2raw

A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment)
MIT License
7.28k stars 1.17k forks source link

Support pluggable obfuscation #381

Open edsburke opened 3 years ago

edsburke commented 3 years ago

udp2raw wire protocol is based on the vanilla mechanism such as AES-128-CBC and HMAC-SHA1. They are quite vulnerable when it comes to DPI. This ticket proposes adding support to pluggable obfuscation, with which in addition to #380, udp2raw can gain wider adoption since it will be served as de facto underlying wire protocol above which most of vanilla VPN can be built to be DPI resistant.

  1. To start, simple-obfs can be integrated as a plugin.
  2. It would be great to port this feature to udp2raw-multiplatform since it affects both client and server side.
wangyu- commented 3 years ago

udp2raw wire protocol is based on the vanilla mechanism such as AES-128-CBC and HMAC-SHA1. They are quite vulnerable when it comes to DPI.

Could you please provide the citation that makes you believe this is true?

To start, simple-obfs can be integrated as a plugin.

simple-obfs is TCP based, stream-oriented. udp2raw's fakeTCP is faked, it's essentially UDP and packet-oriented, I don't know how to make udp2raw and simple-obfs compatible.

edsburke commented 3 years ago

udp2raw wire protocol is based on the vanilla mechanism such as AES-128-CBC and HMAC-SHA1. They are quite vulnerable when it comes to DPI.

Could you please provide the citation that makes you believe this is true?

Thank you @wangyu- for your quick response. I apologize I couldn't find very good references to verify this, but practical field experience of operating VPN shows that traffic using AES based encryption are so easily to be recognized and blocked by GFW DPI. An extra layer of obfuscation can let it circumvent.

To start, simple-obfs can be integrated as a plugin.

simple-obfs is TCP based, stream-oriented. udp2raw's fakeTCP is faked, it's essentially UDP and packet-oriented, I don't know how to make udp2raw and simple-obfs compatible.

I apologize, I omit that udp2raw is essentially UDP, then fakeHTTPS may be the another better option being added?

wangyu- commented 3 years ago

but practical field experience of operating VPN shows that traffic using AES based encryption are so easily to be recognized and blocked by GFW DPI

Is this your personal experience, or you heard it from someone on the internet?

If it's your own experience, could you please explain it a bit? I especially care about how reliable it supports what you claimed. 

edsburke commented 3 years ago

As a result of operating hundreds of nodes, vast amount of field lessons are learnt by ourselves that encrypted (e.g. chacha-ietf-poly1305 or AES series) traffic are so dummy when they come to GFW DPI. Only extra layer of obfuscation such as HTTPs works well till the end of day to avoid being detected and blocked. Here are why in the high level:

  1. Pattern of vanilla obfuscation are specifically targeted and recognized by the DPI.
  2. Obfuscating the traffic as regular HTTPs will cheat DPI since the initial TLS 1.2 handshake is eliminated on purpose to avoid detection. DPI sees them as regular HTTPs traffic but couldn't unveil them due to lack of credentials.
wangyu- commented 3 years ago

traffic using AES based encryption are so easily to be recognized

I thought you were trying to say: AES is worse than chacha20, as in another issue: https://github.com/wangyu-/udp2raw-tunnel/issues/380

encrypted (e.g. chacha-ietf-poly1305 or AES series) traffic are so dummy Only extra layer of obfuscation such as HTTPs works well

But what you were really saying is: an extra layer of obfuscation is better. This might be true.

then fakeHTTPS may be the another better option being added?

The idea sounds more do-able than before, but the same problem still exists. HTTPS is on top of TCP(reliable, stream-oriented). fakeTCP is essentially UDP(unliable, packet-oriented). I don't know any easy way to effectively build a fake HTTPS on top of the already very different underlying layer.

I have previously explained this in:

https://github.com/wangyu-/udp2raw-tunnel/issues/156