If the origin server uses any proper TLS configuration, even a self-signed certificate, this method stops working. It only succeeds when the upstream connection to the origin is unsecured.
If you want to test this on a random site without Cloudflare or reverse proxy in general on HTTP:
curl http://www.digiboy.ir/boobs.jpg -v
To be fair, Cloudflare is also the reason why most sites even have TLS at all, because it offered free certs (through letsencrypt I think?) in a fairly easy to set up way.
Certs used to be expensive, and had way more operational overhead and quirks (even setting up ACME/LE)
How's this work with https like in the example? The hops along the way shouldn't see the path.
Is this implying that all TLS is terminated at the Iran border and proxied from there? And all Iranian sites are required to host via http? That has significantly more implications than what this post is about.
Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
This is referring to something else: to detect whether the backend server host itself is inside or outside Iran. TLS doesn't prevent the backend network from reading the URL of course.
A lot of CF upstreams are (or at least used to be) plaintext. It is one of the criticisms of CF since it "whitewashed" plaintext to look like proper TLS when it was only TLS for client<->CF and then plaintext for CF<->server.
This is a problem for the visitor, not for the server's owner. There is no way to know whether the traffic is encrypted between the server and CloudFlare.
Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
When you type your password into e.g. Hacker News, you are sending that password to the server. It doesn't matter that they're using bcrypt tuned for $1Bn attackers and you chose a sixteen character random alphanumeric string because that precise string, the valid password, is deliberately sent by you, to them, to authenticate and so if they accidentally reveal that or get compromised in any way, game over.
It's getting a little bit better in some areas. My good bank actually has halfway decent security now, but the bank with most of my money (which is owned by my government, and thus avoids any risk consideration - if that bank fails, the currency my money is denominated in also fails, so, it doesn't matter any more) still thinks passwords are a good idea. Google lets me use a Security Key, but most web sites I authenticate with still use passwords.
SSH is slightly better, because of its target audience. A lot of people use public key auth for SSH, which doesn't have this issue. But that's not the web.
Have they started to use per-domain certificates for this, or can anyone who finds the origin bypass the check by creating their own (different) Cloudflare domain and pointing it at your origin?
Edit: Looks still the same by default, but at least they're (somewhat obscurely) documenting the issue and providing the option to use a custom cert now...
> Is this implying that all TLS is terminated at the Iran border and proxied from there?
Yeah, the law-abiding type on the Iranian National Information Network(NIN), either using the Electronic Commerce Council's I.R.Iran CA for HTTPS or just HTTP.
> Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
Due to NIN registrations being not very much not anonymous, https://xkcd.com/538/ seems pretty appropriate if you want to use an unapproved certificate authority.
Would assume it's to check if a site is foreign propaganda. A lot of the lesser-known news sites that you see linked on social media are actually psy-ops pushing an agenda, many of them foreign-based. Follow the technique in the article and you can easily blacklist Iranian ones.
I wonder if this could be broadened to a list of Wikipedia links to humanitarian content folks in repressed regimes are or might get blocked from. Tiananmen Square [1]. Wen Jiabao's staggering corruption [2]. Epstein's e-mails [3]. Et cetera.
Like Netflix launching Fast.com, this would directly weaponise these regimes' censoring tendencies against themselves.
It's a CDN, not an IP router. CDNs usually terminate TCP+TLS as close to the client as possible. This used to be done right at the edge - within the NIC for a long time, but CPUs have been more than capable for the last decade+
Few guesses:
1) CDN connects to backend server over TLS, using the national I.R. Iran root CA
2) CDN connects to backend server over HTTP
3) Backend server is running a nationally blessed Linux OS
For 1 & 2, the National Information Network would be implementing this DigiNotar style but they already own the root keys. For #3, the backend does so itself. These are the people who p0wned DigiNotar after all.
Wow. The screenshot had the IP address exactly where I placed my finger to scroll, and iOS Safari briefly opened a popup window where it started connecting to that IP.
Fuck this shit, I’m moving to a hovel in the woods.
Along the same lines, I occasionally find myself cursing iOS for its willingness to just bring up the dialer and call a number. I really, really wish that it would confirm any dialing before doing it, especially if you didn't click on a phone number on a contact. Couple times I've ended up dialing a recent spam caller, which is the last thing I ever want to do.
Occasionally, if you're lucky enough, an option to copy the phone number shows up, it seems like completely at the whim of the OS. And that's after accidentally starting to dial the number, of course.
Thanks for posting this. I mostly gave up on viewing the one or two Twitter feeds that interest me after nitter stopped working. It wasn't ideological, I just wasn't able to reliably view and navigate without an account, and when I made an account it just kept showing me like "black HS football player bad sportsmanship".
Look like I've got about two years of James Cage White story arcs to check in on.
This behavior only works when the reverse proxy or CDN is configured like this:
Proxy/CDN: HTTPS (443) → Origin server: plain HTTP (80)
(example: Cloudflare in Flexible mode)
If the origin server uses any proper TLS configuration, even a self-signed certificate, this method stops working. It only succeeds when the upstream connection to the origin is unsecured.
If you want to test this on a random site without Cloudflare or reverse proxy in general on HTTP: curl http://www.digiboy.ir/boobs.jpg -v
Ah, Cloudflare. The world's most widely deployed encryption remover.
Is it really that different than AWS? You either trust your service provider or you don't.
To be fair, Cloudflare is also the reason why most sites even have TLS at all, because it offered free certs (through letsencrypt I think?) in a fairly easy to set up way.
Certs used to be expensive, and had way more operational overhead and quirks (even setting up ACME/LE)
Absolutely not, no. That is all thanks to Let's Encrypt.
I'm not going to give them credit for the work that Lets Encrypt did.
It'll also work DigiNotar-style, when using the only root CA blessed by the National Information Network for general use: I.R. Iran.
How's this work with https like in the example? The hops along the way shouldn't see the path.
Is this implying that all TLS is terminated at the Iran border and proxied from there? And all Iranian sites are required to host via http? That has significantly more implications than what this post is about.
Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
This only works on CDNs based in Iran, which are all presumably forwarding the banned requests to some government server.
This is referring to something else: to detect whether the backend server host itself is inside or outside Iran. TLS doesn't prevent the backend network from reading the URL of course.
Well it would if things are setup according to best practises (i.e. use TLS between the backend connections). Presumably most people dont do that.
A lot of CF upstreams are (or at least used to be) plaintext. It is one of the criticisms of CF since it "whitewashed" plaintext to look like proper TLS when it was only TLS for client<->CF and then plaintext for CF<->server.
Has anything ever prevented you from having TLS on your origin server? You can even get a certificate from Cloudflare.
This is a problem for the visitor, not for the server's owner. There is no way to know whether the traffic is encrypted between the server and CloudFlare.
Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
When you type your password into e.g. Hacker News, you are sending that password to the server. It doesn't matter that they're using bcrypt tuned for $1Bn attackers and you chose a sixteen character random alphanumeric string because that precise string, the valid password, is deliberately sent by you, to them, to authenticate and so if they accidentally reveal that or get compromised in any way, game over.
It's getting a little bit better in some areas. My good bank actually has halfway decent security now, but the bank with most of my money (which is owned by my government, and thus avoids any risk consideration - if that bank fails, the currency my money is denominated in also fails, so, it doesn't matter any more) still thinks passwords are a good idea. Google lets me use a Security Key, but most web sites I authenticate with still use passwords.
SSH is slightly better, because of its target audience. A lot of people use public key auth for SSH, which doesn't have this issue. But that's not the web.
I've set up CF for a personal site and I even tell CF to use a client certificate (called "Origin CA") so nothing else can even connect to it.
Have they started to use per-domain certificates for this, or can anyone who finds the origin bypass the check by creating their own (different) Cloudflare domain and pointing it at your origin?
Edit: Looks still the same by default, but at least they're (somewhat obscurely) documenting the issue and providing the option to use a custom cert now...
https://developers.cloudflare.com/ssl/origin-configuration/a...
> Is this implying that all TLS is terminated at the Iran border and proxied from there?
Yeah, the law-abiding type on the Iranian National Information Network(NIN), either using the Electronic Commerce Council's I.R.Iran CA for HTTPS or just HTTP.
> Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
Due to NIN registrations being not very much not anonymous, https://xkcd.com/538/ seems pretty appropriate if you want to use an unapproved certificate authority.
I'm wondering for what purpose one would be interested in finding out if a site is hosted in Iran or not.
Would assume it's to check if a site is foreign propaganda. A lot of the lesser-known news sites that you see linked on social media are actually psy-ops pushing an agenda, many of them foreign-based. Follow the technique in the article and you can easily blacklist Iranian ones.
I don’t buy psy-ops unless it’s American-made
I'd rather not do business there.
It’s illegal for US companies to do business with anyone in Iran.
Im guessing - its for some protest action? ... but really I have NO IDEA.
So does this mean 10.x.x.x is publicly routable inside iran? Why wouldn't the Iranian government just use its own ip space for the censorship message?
Does anyone have sample sites that return this?
Also interested in a sample site where the request successfully resolves ;)
If search in google search with site:ir it returns lots .ir links. I clicked on one and it went to a .com domain site.
This may or may not be useful. How all this works is beyond my knowledge ..
Are you asking if there are pictures of boobs on the internet?
I wonder if this could be broadened to a list of Wikipedia links to humanitarian content folks in repressed regimes are or might get blocked from. Tiananmen Square [1]. Wen Jiabao's staggering corruption [2]. Epstein's e-mails [3]. Et cetera.
Like Netflix launching Fast.com, this would directly weaponise these regimes' censoring tendencies against themselves.
[1] https://en.wikipedia.org/wiki/1989_Tiananmen_Square_protests...
[2] https://www.nytimes.com/2012/10/26/business/global/family-of...
[3] https://jmail.world
So presumably Iran has a reverse proxy in front of the entire internet for HTTP?
I really want to know what's on the webpage for the iframe.
> So presumably Iran has a reverse proxy in front of the entire internet for HTTP?
Standard DPI firewalls can do that for you. Absolutely no issue.
For the path component, in a TLS secured request?
It's a CDN, not an IP router. CDNs usually terminate TCP+TLS as close to the client as possible. This used to be done right at the edge - within the NIC for a long time, but CPUs have been more than capable for the last decade+
Few guesses:
1) CDN connects to backend server over TLS, using the national I.R. Iran root CA
2) CDN connects to backend server over HTTP
3) Backend server is running a nationally blessed Linux OS
For 1 & 2, the National Information Network would be implementing this DigiNotar style but they already own the root keys. For #3, the backend does so itself. These are the people who p0wned DigiNotar after all.
Wow. The screenshot had the IP address exactly where I placed my finger to scroll, and iOS Safari briefly opened a popup window where it started connecting to that IP.
Fuck this shit, I’m moving to a hovel in the woods.
Along the same lines, I occasionally find myself cursing iOS for its willingness to just bring up the dialer and call a number. I really, really wish that it would confirm any dialing before doing it, especially if you didn't click on a phone number on a contact. Couple times I've ended up dialing a recent spam caller, which is the last thing I ever want to do.
On top of that, the only possible interaction with the number is to call it or to not call it.
Want to copy the number into the clipboard to call it later, call it from a different app, or forward it to somebody else? Tough luck.
There are a few options available if you press and hold it (Call, Message, Add to Existing Contact, Create New Contact, Delete).
I feel this only make the fact that tapping calls without confirmation more annoying though.
Occasionally, if you're lucky enough, an option to copy the phone number shows up, it seems like completely at the whim of the OS. And that's after accidentally starting to dial the number, of course.
iOS presents me with "Dial NPA-NXX-XXXX" and "Cancel" options in a bottom-raised dialog, when I tap a tel link.
I don't recall doing anything special to make this happen, but I wouldn't put it past me.
That may be specific to a web browser hyperlink. Click on an entry in your recent calls list and it'll immediately dial the number that called you.
Got it, I missed the context.
Agreed, now that I remember the self-training I had to do to avoid the issue, this is an obnoxiously awkward design choice!
It’s in a private Ip range so unless you’re inside Iran you’re fine.
Agree it's a stupid default but you can (and imo should) turn off link previews in iOS
I saw “boobs” so I ran.
-Iran
Why not?
https://xcancel.com/hkashfi/status/1995109785679573167
Thanks for posting this. I mostly gave up on viewing the one or two Twitter feeds that interest me after nitter stopped working. It wasn't ideological, I just wasn't able to reliably view and navigate without an account, and when I made an account it just kept showing me like "black HS football player bad sportsmanship".
Look like I've got about two years of James Cage White story arcs to check in on.
This has been so useful to me that I've created a filter in URLCheck[0] that automatically converts all X-related links.
[0] https://github.com/TrianguloY/URLCheck
Why does this work while nitter doesn’t?