You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://ntc.party/t/http-headers-tls-padding-as-a-censorship-circumvention-method/168/2
The idea is to fill TLS ClientHello with lots of padding (14+ kB), adding SNI extension only after the padding. This method, compared to strip-sni or replace-sni, correctly works with ~all servers.
DPI systems usually have limited reassembly buffer which rarely exceed 8 kB, that's why it's effective to overflow it.
The text was updated successfully, but these errors were encountered:
Thanks for the interesting suggestion, unfortunately, the basic proxy server very much limits my ability to add some low-level things.
After some time in search, it became clear that it is impossible to modify ClientHello with standard Netty APIs - this can be done only by manually modifying the packet bytes. To do this, it's needed to add a handler, which, if I understand correctly, should be called before the SSL handler, but in this case it receives a buffer containing deliberately incorrect data.
I'll try to find another way to intercept ClientHello and tell if I succeed :(
https://ntc.party/t/http-headers-tls-padding-as-a-censorship-circumvention-method/168/2
The idea is to fill TLS ClientHello with lots of padding (14+ kB), adding SNI extension only after the padding. This method, compared to strip-sni or replace-sni, correctly works with ~all servers.
DPI systems usually have limited reassembly buffer which rarely exceed 8 kB, that's why it's effective to overflow it.
The text was updated successfully, but these errors were encountered: