X-Clacks-Overhead(hleb.dev)
hleb.dev
X-Clacks-Overhead
https://hleb.dev/post/x-clacks-overhead/
47 comments
What supposed problems does it cause in practice?
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?"
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.
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.
> If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.
oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.
oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.
X-Do-Evil: true
Do-Evil: falseSmuggling 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)
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.
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!
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!
It might not have but it's a lot more likely that it would.
[deleted]
There's a list of sites broadcasting X-Clacks-Overhead: https://xclacksoverhead.org/listing/the-signal
I have been guilty of adding a custom header to all of my emails: "Yo-Momma: Fat". For years. In a professional setting. Nobody noticed.
Discovering this at work one day would have brought a smile to my face!
Perhaps there's a whole new joke format here.
Long-Face-Reason: horse
Perhaps there's a whole new joke format here.
Long-Face-Reason: horse
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.
My blog has had this header since the day he died.
The Night Watch seems pretty gritty to me. And Small Gods. And Vimes' escape from the werewolves in The Fifth Elephant.
Night Watch is my favourite book of his, as it turns out. He is capable of exploring serious themes while still maintaining some whimsy. That's why I love him so much.
There are Chrome and Firefox extensions to indicate the presence of the header.
https://chromewebstore.google.com/detail/clacks-overhead-gnu...
https://addons.mozilla.org/en-US/firefox/addon/x-clacks-over...
https://chromewebstore.google.com/detail/clacks-overhead-gnu...
https://addons.mozilla.org/en-US/firefox/addon/x-clacks-over...
stackoverflow.com and all stack exchange sites also include X-Clacks-Overhead in the response thanks to yours truly
GNU Terry Pratchett
"A man never truly dies until the his name is no longer spoken."
"A man never truly dies until the his name is no longer spoken."
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 am all for goofy headers. Its especially fun when randomly stumbling into it.
The most important HTTP header (though clacks is a packet routing system, not an application-level streaming protocol)
True, perhaps it should be added as an IP option field or TCP option...
Honeypots are advertising that header as well nowadays:
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
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
A while back I wrote a tiny piece of Phoenix middleware to add the GNU message for an arbitrary name to phoenix applications:
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"
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"
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…
[deleted]
You don't need cloudflare workers for that. The blog post mentioned how to add it. And there are other options as well.
I have a fully static site. And the backing storage doesn’t let me set custom headers
Did you read the article? That method doesn't work for you?
What about this one? https://developers.cloudflare.com/rules/transform/request-he...
What about this one? https://developers.cloudflare.com/rules/transform/request-he...
> But sometimes small, unnecessary things are exactly what make the internet better.
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.
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.
Is this possibly an intentional reference to GNU Linux, or unrelated?
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:
https://wiki.lspace.org/GNU_Terry_Pratchett
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.
https://wiki.lspace.org/GNU_Terry_Pratchett
Quite intentional.
It's Terry Pratchett, so of course it's an intentional reference.
Looks like the site uses the deprecated "Report-To:" header in responses too, something I've never seen before and had to lookup.
Whenever you load my blog, it randomly sends back a name from my configuration's clackset: https://github.com/Xe/site/blob/ff8627975e5f6718fff33051d11a.... I hate that the list is so long but over time it will only grow longer.
Does “saying the name lest he be forgotten” classify as Cargo Cult?
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.
I was curious, and you’re right. It would be Cargo Culting then, if we believed the ritual actually had an effect on Pratchett in the afterlife.
Surely not. That's just most religions.
Cargo cults are quite specifically believing that the incantations have an effect in this world.
"The first documented cargo cults were religious movements that foretold followers would imminently receive an abundance of (often Western) food and goods (the "cargo") brought by their ancestors."
https://en.wikipedia.org/wiki/Cargo_cult
Cargo cults are quite specifically believing that the incantations have an effect in this world.
"The first documented cargo cults were religious movements that foretold followers would imminently receive an abundance of (often Western) food and goods (the "cargo") brought by their ancestors."
https://en.wikipedia.org/wiki/Cargo_cult
> 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