Comment by losvedir 3 days ago
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?
Again, you are assuming a normal situation. The point is the country itself is operating (or has a heavy grip and perhaps even subsidizes) the backend CDN and enforcing that stuff in a rudimentary way.
"TLS between backend connections" usually involves termination and decryption on the frontend webserver and re-encryption of the upstream traffic, whatever it may be.
Has anything ever prevented you from having TLS on your origin server? You can even get a certificate from 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.
> 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.
Any server could be leaking plaintext data, sure, but Cloudflare offers and even promotes wrong-thing-as-a-service.
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.
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.