Follow

Dear IETF: Are you fucking kidding me?
To get an RFC .txt file I must allow Cloudflare and Google tracking?

Are you serious? This is wrong on all OSI layers!

@lanodan Thanks for sharing. I do have my local RFC backup as well. (Not really current though to be honest.)
Still… the IETF must not block users in any way. (“must not” to be interpreted as defined in RFC 2119.)

@MacLemon @lanodan The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

@M0YNG
I think it depends on from where you happen to exit. Try a new circuit with Ctrl+Shift+L
@MacLemon

@M0YNG still there would be cloudflare involved, it does not protect to from that, they just wouldn't know who is actually accessing the ressource.

@MacLemon @M0YNG In the past I've seen different results - regarding this topic - between regular Firefox with tor (daemon) + privoxy versus Tor browser.

@Ajz @MacLemon @M0YNG likely it depends on the tor exit? I suppose cloudflare could attempt "is this a browser" javascript tests..

@jasper That was a request to a .txt file. So, nope, they cannot test for .js in that case. I mean, sure they *can* but it will fail 100% meaning it‘s a pretty useless test, not only in this case.
Either way, among many institutions on the internet, the IETF is probably one of the least in the position to cause any blockings caused by their contractors. Especially given their requirements for internet access at IETF meetings it‘s really hard to understand why they‘d block anything.

@MacLemon pretty sure you can serve up a html file when the extension is .txt? If you put another filetype in the header, it has precedence.. It's actually demonstrated in the screenshot; It's not showing the HTML as text. (it'd run javascript too, likely uMatrix is blocking it, and the frame)

FTR cloudflare sucks.. I am not really fishing for "reasons it makes sense for Cloudflare/IETF to do this".

@jasper The IETF does indeed serve text/plain on that URL. As expected, as they should.

Cloudflare does the MITM attack here by messing with everything they can for no observable reason. And yes, of course uMatrix blocks 3rd party frames/.js. It‘s obviously for a good reason to do so.
I understand what‘s going on here, I‘m just not willing to accept that shit, especially from the IETF.

@MacLemon did you consider writing them an email or so, informing about what they do wrong and ask for the document you need to be send by email?

@utzer I'd rather gopher that file. I really hate Email.
But you're right, I should drop them a note of that problem.

@MacLemon yes, I can understand the hesitation, but if nobody tells them they will not change it.

@utzer I would be quite astonished if they weren't aware of the problem at all. But just maybe their ops are less considerate than other IETF people. Not impossible, just very unlikely.

@MacLemon I meant more like they are not aware of the problem as in they are not aware it is a problem for some people.

@MacLemon
Just tried. No cloudflare, no captcha, just txt (also html). Both Torbrowser and direct without any extra allowance in uMatrix and nothing blocked. No other domain.

@erAck @MacLemon But who issued the certificate? If it's from Cloudflare, then – they do MITM as their business model, so you can't tell from the domain name.

@IceWolf

O=Starfield Technologies, Inc.
CN=Starfield Secure Certificate Authority - G2

@MacLemon

@erAck cloudflare usually uses the main domain, did you check the IP you connect to? Thy usually have the AAAA and A set to one of their IPs.

@Utzer

Ah true, https connects to 104.20.1.85 which is CLOUDFLARENET

dig www.ietf.org a
CNAME www.ietf.org.cdn.cloudflare.net.
IN A 104.20.1.85

@erAck @utzer Yeah, saw that! Unfortunately it doesn't help when connecting via HTTPS. I did an `openssl s_client -connect www.ietf.org -port 443` to it, ran lsof to see what it was connecting to, and it was the Cloudflare one.

@IceWolf

And without www. it's not.
Btw, using curl is more convenient:
curl -iIsSv ...

@Utzer

@erAck @utzer Oh, I did use the www one, didn't I! Derp, thanks. *facepaws*

@drwetter

Same 180s for the ietf.org (without www.) direct connection.

@IceWolf @Utzer

@MacLemon www.rfc-editor.org doesn't use cloudflare: rfc-editor.org/rfc/

But none the less a shitty thing to do from the ietf.

@MacLemon I just checked; ftp still works to that address.

(I think that is the only way I have ever read an rfc, to be honest. Well, no, I have read them via links - but always mirrored, I believe. I believe the only way I've gone to the ietf website was via ftp. Thus my concern: was my traditional method now not working? And, no, it still does.)

@MacLemon ... I never experienced that, and I don't see anything about Cloudflare or Google. These are the only two requests that page makes for me.
image.png

@laggard You may want to check to whose IPs that hostname resolves to…

@MacLemon b-but what if someone ddoses the IETF website? would be too much to expect them to have their own infrastructure to handle it

@epi I don't mind them using a CDN, but I do mind them blocking legitimate requests via their CDN.

@MacLemon you can download them over ftp too, so don't even bother with the http version if this happens to you.

ftp://ftp.ietf.org/rfc/
Sign in to participate in the conversation
chaos.social

chaos.social – a Fediverse instance for & by the Chaos community