Originally published on proxymint.
HTTP2 fingerprinting reads the SETTINGS, WINDOW_UPDATE, PRIORITY and pseudo-header order a client sends first. Real values from Chrome, Firefox and Go.
TL;DR
- HTTP/2 fingerprinting reads how a connection opens. The server records the client's SETTINGS values and order, its first WINDOW_UPDATE, any PRIORITY frames and the pseudo-header order, and turns them into one string.
- Each client library sends different values. Chrome opens a 15 MB connection window and orders pseudo-headers m, a, s, p; Firefox opens 12 MB with m, p, a, s; Go's x/net transport opens 1 GB with a, m, p, s.
- It works together with the TLS fingerprint. ALPN in the handshake, the HTTP/2 frames, the header order and the User-Agent all have to agree; a script claiming to be Chrome fails on the first mismatch.
- A tunnelling proxy changes none of it. CONNECT and SOCKS5 relay the encrypted stream, so the HTTP/2 frames are the client's; the exit changes the IP, the network and the TCP stack.
Key takeaways
- Capture your own fingerprint on a server you control. Run nghttpd in verbose mode and compare a browser request with a script request, direct and through your proxy.
- Match the client to its claim. Traffic that says Chrome should come from a Chrome engine; a script should send an honest User-Agent instead of a borrowed one.
- Do not expect a new IP to fix a client signal. The HTTP/2 string is identical through any tunnelling proxy, so rotating exits will not change a score built on it.
- Pick the egress category for the IP-side checks. Datacenter where hosting networks are accepted, residential where a home connection is expected, mobile where a carrier origin is.
Read the full guide on proxymint, with the commands, tables and sources.
Top comments (0)