FYI - no need to prefix your custom header with X- !
> Historically, designers and implementers of application protocols
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
If a nonstandard X header becomes widely used and then adopted as the standard, there is a surprisingly lengthy and difficult transition period to the new name.
Both clients and servers have to support both the X name and the regular name for decades, and servers have to deal with questions like "What if both are present but different?"
If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.
Sending two headers seems fine in most cases.
These are certainly downsides but hardly dealbreakers. On the other side, not prefixing has its own pros & cons, which seem more difficult to work around:
1. The obvious clash issue. If two pieces of software implement entirely different X-Value: headers, the standardisation effort clarifies the signal in the form of an unprefixed version. If both competing software applications start out unprefixed, the signal will always be ambiguous.
2. Implementation changes. If any lessons are learnt during initial use of a prefixed header, these can be applied by standardising on a slightly improved unprefixed version.
Smuggling is a general concern whenever two headers have functionality that interact - it's not specific to prefix masking & given how implementation-based it is, it's not even likely to occur to any arbitrary prefix mask.
That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
But isn't the problem with X- headers that if they ever get standardised, they necessarily create this smuggling issue? Whereas if you start with an unprefixed header and standardise it under the same name, you avoid this issue.
You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.
> That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!
I miss Terry Pratchett. Just a good guy, writing joyful books. None of that "gritty realism" here. There's only about 40 books by him, so I read 2 a year. By the time I get to 40, I figure I would have forgotten the first few and I can start again.
My blog has had this header since the day he died.
I think strictly speaking any node on the network which receives the header should forward it on. So if your browser ever sees it, it should use it for all HTTP requests from that point. And if a server ever receives it, it should pass it to all clients.
I had that header set back when I ran my blog on my own HTTP server. Probably should spend some Cloudflare worker cycles to put it back now that it’s purely static…
Within the book itself the clacks system has its own technical protocol which is briefly touched upon. The "overhead" is essentially packet or request metadata.
From the LSpace wiki, GNU is a metadata that means:
G: Send the message onto the next Clacks Tower.
N: Do not log the message.
U: At the end of the line, return the message.
And yes, it is almost certainly a reference to GNU as in "GNU's Not Unix". =)
Why would it? Cargo Cutlting is when you believe that doing something symbolic will have a tangible effect on the world (e.g. bring you cargo from the sky), but this is just intended to be symbolic.
> Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.
https://datatracker.ietf.org/doc/html/rfc6648
Both clients and servers have to support both the X name and the regular name for decades, and servers have to deal with questions like "What if both are present but different?"
Sending two headers seems fine in most cases.
These are certainly downsides but hardly dealbreakers. On the other side, not prefixing has its own pros & cons, which seem more difficult to work around:
1. The obvious clash issue. If two pieces of software implement entirely different X-Value: headers, the standardisation effort clarifies the signal in the form of an unprefixed version. If both competing software applications start out unprefixed, the signal will always be ambiguous.
2. Implementation changes. If any lessons are learnt during initial use of a prefixed header, these can be applied by standardising on a slightly improved unprefixed version.
oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.
That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!
Perhaps there's a whole new joke format here.
Long-Face-Reason: horse
My blog has had this header since the day he died.
https://chromewebstore.google.com/detail/clacks-overhead-gnu...
https://addons.mozilla.org/en-US/firefox/addon/x-clacks-over...
https://www.shodan.io/search/report?query=x-clacks-overhead
Most of the non-honeypot results are for the Gargoyle Router Management interface exposed by Korea Telecom:
https://www.shodan.io/search/report?query=x-clacks-overhead+...
The results have increased significantly over time:
https://trends.shodan.io/search?query=x-clacks-overhead
Sadly no additional challenge other than "If you are reading this, please consider a technology job at AT&T www.att.jobs".
What about this one? https://developers.cloudflare.com/rules/transform/request-he...
Or, worse? I don't think this is the point you're wanting to make but it's not always the case that it's better.
"A man never truly dies until the his name is no longer spoken."
From the LSpace wiki, GNU is a metadata that means:
And yes, it is almost certainly a reference to GNU as in "GNU's Not Unix". =)https://wiki.lspace.org/GNU_Terry_Pratchett
https://github.com/alex0112/ex_clacks_overhead
I haven't touched it in years, so it's possible that it no longer works. But maybe this post is a kick in the pants for me to go test it again.
Thanks for keeping it in the overhead. GNU Terry Pratchett.
> "A man's not dead while his name is still spoken"