Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

sshuttle as described sounds like a normal CONNECT proxy which this is able to detect: https://sshuttle.readthedocs.io/en/stable/how-it-works.html

like its similar to connect or socks proxy except it is using SSH as a transport layer instead of TCP as a transport layer and its doing it transparently without having applications to be written to use the proxy. but if you are just converting TCP packets into a datastream and then sending them somewhere else where you convert them back to TCP packets then this is what this TCP RTT strategy is fundamentally meant to detect. i suspect the TCP only RTT thing works because of the delayed ack behaviour of most operating systems and this will still happen with sshuttle unless you are explicitly using quick-ack. also, quick-ack just works around the TCP-RTT issue and not the differences in timing between TCP and TLS or other higher protocols. i think if you are testing for other RTT differences then quick-ack would make them more obvious.

on the server side sshuttle just uses normal tcp sockets and nothing magic (https://github.com/sshuttle/sshuttle/blob/master/sshuttle/ss...)

also, if you have an sshuttle proxy this site cannot detect it may be due to how close the server is to the client. i have a CONNECT based proxy it is able to detect around 5% of the time (maybe only that often due to a bug) but this is because there is probably less than 10ms latency between the proxy and the client and probably around 50ms latency between the proxy and the server for some reason (?).





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: