Sing-box removed hidden metadata transmission in AnyTLS: it was used to profile users

Proxy and Virtual Private Networks
, , ,
1

Cover
Cover1280×670 25.1 KB

Yesterday, August 3, released sing-box 1.14.0-beta.5 and stable 1.13.16. Formally — ordinary releases, but the changelog of both hides a line that deserves separate consideration: the client implementation of the AnyTLS protocol sent metadata to the server that the open-source server doesn’t need at all, — and, according to the sing-box team, some vendors have already used it for profiling users. Now sending is disabled by default. Let’s unpack exactly what leaked, who could see it, and what to do.

Briefly about AnyTLS — for those who missed it

AnyTLS is a young protocol devised as a response to the problem of TLS-in-TLS fingerprinting: when DPI recognizes a proxy not by content, but by the characteristic “handwriting” of the embedded TLS handshake. Against this AnyTLS uses flexible padding schemes — configurable rules for cutting and supplementing the first packets of a session to blur the signature — plus multiplexing connections to reduce latency. The protocol is supported by sing-box (since v1.12), mihomo, Shadowrocket (since v2.2.65) and the reference anytls-go; in our region it is often tested as an alternative to VLESS+Reality and ShadowTLS.

What exactly leaked

According to the AnyTLS specification, the client immediately after authentication sends to the server a Settings frame — a set of key=value pairs. It looks like this:

v=2
client=sing-box/1.13.x
padding-md5=<md5-hash of the active padding scheme>

That is, the server receives: the protocol version, the name and version of the client software and the hash of the padding scheme. The standard open server does not need the field client= for anything — it simply ignores it. But if the server is controlled by a commercial vendor with a modified implementation, the picture is different: through these fields you can determine which application and which version the client is using (and from them the platform is often inferred), and by padding-md5 — group users with identical configurations. The release wording is concise:

We found that the AnyTLS client implementation uploads metadata that is not used by the open-source server, and some vendors use it to profile users.

How serious is this

It’s important to calibrate the threat, without panic, but also without sweeping it under the rug. The metadata went to your own proxy server, not to a third party. So if you host both the client and the server — this hardly changed anything for you: your own server already sees your IP and traffic. The risk was for those who connect to other servers — commercial VPN services and shared panels: they received a free telemetry channel that users did not realize. And the irony: the protocol designed to hide the fingerprint from DPI voluntarily handed the client fingerprint to the server.

This is not de-anonymization and not RCE, but a notable precedent: “extra” fields in protocols tend to find uses, and it’s good that sing-box cleaned them by default rather than hiding them behind a checkbox to “disable telemetry.”

What to do

  • Update clients to 1.13.16 (stable branch) or 1.14.0-beta.5: this fixes the client specifically. The set of sent metadata can now be defined manually in the config — by default nothing extra is sent.
  • Keep the panel or distribute subscriptions (Remnawave/Marzban-scenarios with sing-box clients) — remind users to update: the server doesn’t decide this.
  • Check the version easily:
sing-box version
# docker variant:
docker compose pull && docker compose up -d
  • The general hygiene rule remains: when connecting to someone else’s server, assume it can see everything that the client reports.

Also: why the 1.14 branch is worth watching

The fix arrived in the beta of a branch that promises to be the most feature-rich in the last year and a half:

  • client and server OpenVPN + client OpenConnect — you’ll be able to assemble a corporate VPN and obfuscated traffic in one config and one routing, without a second daemon;
  • the Snell protocol;
  • JSON Schema and the sing-box schema command — autocomplete and config validation directly in the editor; those who’ve battled typos in route rules in prod will appreciate this most;
  • parallel DNS response handling and new rules for search domains;
  • TLS spoofing and per-rule TLS settings;
  • official desktop app for Windows and Linux;
  • network namespaces on Linux and L3 forwarding with TUN.

Judging by the beta pace (beta.5 in a few weeks), stable 1.14.0 is not far away — but there’s no need to wait for an AnyTLS fix; it’s already in stable 1.13.16.

Sources

Who is already running AnyTLS in production — how does it fare against VLESS+Reality under active DPI? And how do you like the all-in-one sing-box experience, up to OpenVPN: convenience or an extra attack surface?