What TCP MSS Reveals About the Path

Intro

A TCP SYN packet is small, but it is not empty. Buried in the options is Maximum Segment Size: the largest chunk of data this side claims it can accept. Security products often treat MSS as a fingerprint of the operating system. That is the wrong layer of the story.

MSS is a receipt for the path. It tells you what the stack thinks the next hop can carry after IP and TCP headers, after PPPoE, after a VPN envelope, after a mobile radio that already spent bytes on its own framing. When the number moves, the machine may still be the same. The tunnel in the middle usually is not.

Fraudnode reads this field on the SYN that hits the collector, together with the rest of the TCP option set. The point is not to nickname the laptop. The point is to notice when the wire and the User-Agent are telling different stories.

What the number actually is

Ethernet still dominates last-mile and data-center access with a 1500-byte MTU. Subtract a 20-byte IPv4 header and a 20-byte TCP header with no options, and you get 1460. That is why 1460 shows up so often in desktop traffic. It is not a Windows logo. It is arithmetic.

If the path uses IPv6, the IP header is larger and MSS drops. If the stack advertises TCP options, those bytes live in the SYN itself; they do not change the MSS formula, but they do change how long the SYN looks on the wire. If someone stuffed a GRE, WireGuard, OpenVPN, or HTTP CONNECT hop in front of the browser, the inner TCP session often learns a smaller effective MTU. The SYN then arrives with a modest MSS even though the laptop would have been happy with 1460 on a clean Ethernet jack.

Mobile networks add another cut. Cellular and some Wi-Fi setups run with a lower MTU than office Ethernet. Clean phones therefore scatter across several well-known values instead of sitting on a single spike. That scatter is not automatically a proxy. It is what a radio path looks like.

Very large MSS values, in the jumbo-frame range around nine kilobytes, almost never come from a home browser. They are a data-center smell: two machines that already agreed to carry bigger frames on a private fabric.

Why tunnels move the spike

Encapsulation spends bytes. Every extra header must fit inside the outer MTU, so the inner TCP session is told to send smaller segments. VPN clients, cloud load balancers, and some residential proxies do this as a matter of course. The browser still believes it is Chrome on Windows. The SYN no longer looks like a Windows box on Ethernet.

That mismatch is useful because it is mechanical. You do not need the vendor's marketing name for the tunnel. You see that a stack which almost always announces 1460 on a direct path is suddenly announcing something that only appears after an extra envelope.

The reverse mistake is just as important. A phone on LTE with a naturally lower MSS is not a VPN just because the number is not 1460. Mobile clean traffic is noisy. Treating every dip as fraud is how you train users to ignore the product.

The SYN is more than MSS

MSS travels with company. Window Scale, timestamps, SACK permitted, and a handful of NOPs for alignment are the usual companions. RFC 1323 (updated by RFC 7323) lets a stack scale the 16-bit window field so a long fat network can keep more data in flight. The scale factor is agreed only on SYN. It does not change mid-connection.

Different kernels historically pack those options in different orders and lengths. The captured SYN is therefore a little longer on some families than on others: extra options add bytes. That length is a hint about which option set was built, not a serial number. A middlebox that rewrites the handshake can make a Mac look like a Linux box on this axis alone.

Some stacks, especially older Linux profiles, embedded devices, and a few proxies, set the initial window to a multiple of MSS instead of the familiar 65535. Search scanners are famous for odd windows. Again, this is a path and stack story. It is evidence to combine, not a rule to tattoo on a dashboard.

How to read it without lying to yourself

Use MSS as a consistency check.

If a session claims to be a desktop on a wired network and the SYN carries the Ethernet default, the path is at least plausible. If the same claim arrives with an MSS that only shows up after encapsulation, you have a question, not yet a verdict. If a mobile client spreads across several radio-like values, that is the base rate, not an incident.

Never promote a single threshold into a product decision. Thresholds rot when vendors ship a new VPN, when a carrier changes MTU, when a browser starts talking HTTP/3 on a different handshake. The honest output is: the TCP option set and the advertised MSS do or do not match the rest of the session.

That is also why Fraudnode fails closed. If the SYN never arrives, there is no MSS to interpret. The check does not invent a 1460 and wave the client through.

What to look at next

MSS is the easy field because everyone can compute 1500 minus headers. The harder, and more stable, work is the rest of the SYN: option order, scale, timestamps, and whether the window is a round multiple of the segment size. Those sit in the same packet. They cost nothing extra to collect.

HTTP/2 SETTINGS and TLS ClientHello live one layer up. They answer a different question: which library built this request. MSS answers who resized the pipe. You want both. You do not want to confuse them.