←back to thread

Curl-impersonate: Special build of curl that can impersonate the major browsers

(github.com)
545 points mmh0000 | 3 comments | 03 Apr 25 15:24 UTC | HN request time: 0s | source
Show context
ryao ◴[03 Apr 25 18:57 UTC] No.43573858[source]▶
Did they also set IP_TTL to set the TTL value to match the platform being impersonated?

If not, then fingerprinting could still be done to some extent at the IP layer. If the TTL value in the IP layer is below 64, it is obvious this is either not running on modern Windows or is running on a modern Windows machine that has had its default TTL changed, since by default the TTL of packets on modern Windows starts at 128 while most other platforms start it at 64. Since the other platforms do not have issues communicating over the internet, so IP packets from modern Windows will always be seen by the remote end with TTLs at or above 64 (likely just above).

That said, it would be difficult to fingerprint at the IP layer, although it is not impossible.

replies(3): >>43573901 #>>43574995 #>>43576160 #
gruez ◴[03 Apr 25 20:31 UTC] No.43574995[source]▶
>That said, it would be difficult to fingerprint at the IP layer, although it is not impossible.

Only if you're using PaaS/IaaS providers don't give you low level access to the TCP/IP stack. If you're running your own servers it's trivial to fingerprint all manner of TCP/IP properties.

https://en.wikipedia.org/wiki/TCP/IP_stack_fingerprinting

replies(1): >>43578648 #
1. ryao ◴[04 Apr 25 05:30 UTC] No.43578648[source]▶
I meant it is difficult relative to fingerprinting TLS and HTTP. The information is not exported by the berkeley socket API unless you use raw sockets and implement your own userland TCP stack.
replies(1): >>43583773 #
2. sneak ◴[04 Apr 25 15:24 UTC] No.43583773[source]▶
Couldn’t you just monitor the inbound traffic and associate the packets to the connections? Doing your own TCP seems silly.
replies(1): >>43585033 #
3. gruez ◴[04 Apr 25 16:54 UTC] No.43585033[source]▶
Yeah, some sort of packet mirroring setup (eg. in iptables or at the switch level) + packet capture tool should be enough. Then you just need to join the data from the packet capture program/machine with your load balancer, using src ip + port + time.