It has been reported that the DPI systems in Saudi Arabia and
United Arab Emirates are started to search for the beginning of
SNI extension header and its value, without parsing the TLS ClientHello
packet, in any part of TCP session.
Workaround the issue by splitting the packet right after the end
of extension headers and before its value.
https://ntc.party/t/goodbyedpi-in-saudi-arabia/7884https://ntc.party/t/goodbyedpi-in-uae/7914
If --max-payload 1200 is used and there's HTTP request with lots of cookies
which exceed 1200 bytes in size, this packet would have been skipped as
'too large', and the circumvention won't be applied.
Fix this by checking for "GET " or "POST" in the beginning of the packet
regardless of its size.
It was assumed that getopt checks argc count and does not require
null-terminated argv pointer to determine argv end for optional
parameter.
That is wrong.
Add null-terminated latest argv.
Fixes#246
This option excludes TCP packets with the data payload larger than
defined value from being copied by WinDivert driver to GoodbyeDPI.
As most of HTTP and TLS ClientHello packets are repatively small,
and file transfers are usually big and are sent/received using
the whole available MTU/MSS, we can just exclude them from
being processed by our userspace program to reduce unnecessary
CPU load.
This option is added specially for protonmail.com, as it sends
low Window Size in SYN-ACK for requests from Russia, to force
the client to fragment the packet. GoodbyeDPI doesn't do reassembling
and can't extract SNI in this case, thus won't circumvent the
censorship if --blacklist option is used.
This patchset adds maximum TTL size of the fake packet to be sent,
to further improve compatibility with asymmertic routing and
non-standard TTL value set on servers.
Say you set --auto-ttl to 4.
If the TTL distance to the destination host is too short, say 6, auto-ttl
would decrease it by 4 and send a fake packet with TTL 2, which is too low
for the packet to travel via DPI system.
But if you set --auto-ttl to a lower value such as 2, that may introduce
issues over long lines where outgoing-path TTL and incoming-path TTL may have
difference more than 2 hops due to higher chance of assymetric routing along
the path.
To solve this issue, this commit introduce auto-ttl range of two values.
If the incoming TTL distance is more than autottl2, it is subtracted by
autottl2 value.
If the distance is less than autottl2, the distance value is used as a
normalized weigth of [autottl1; autottl2] scale.
The simplified formula is as follows:
128 > extracted_ttl > 98: // Server is running Windows
nhops = 128 - extracted_ttl
64 > extracted_ttl > 34: // Server is running Linux/FreeBSD/other
nhops = 64 - extracted_ttl
if (nhops - autottl2 < autottl2)
ttl_of_fake_packet = nhops - autottl1 - trunc((autottl2 - autottl1) * ((float)nhops/10));
else
ttl_of_fake_packet = nhops - autottl2
