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
I didn't quite get if Automatic TLS (https://developers.cloudflare.com/ssl/origin-configuration/s...) could use plain transfers.
So:
* Is it insecure by default or you have to be intentionally insecure?
* Why would anyone pick the flexible/potentially-insecure option?
Certs used to be expensive, and had way more operational overhead and quirks (even setting up ACME/LE)
Granted, most CDNs these days have some form of free certicate system, but that wasn't always the case.
And i say this as someone who uses ACME in certmanager and certbot at home and still prefers the ease with which Cloudflare generates a cert for my domain and terminates TLS for the public side of my cloudflare tunnel.
On a side note, nginx doesn't support HTTP/2 for https load balancing so I am thinking of switching to haproxy which supports it
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?
"TLS between backend connections" usually involves termination and decryption on the frontend webserver and re-encryption of the upstream traffic, whatever it may be.
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.
Any server could be leaking plaintext data, sure, but Cloudflare offers and even promotes wrong-thing-as-a-service.
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...
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.
Iran is actively working hard to make us hate our fellow citizens. That matters.
They have well known active operations of helping fuel the flames of political division by amplifying both sides of extremely divisive topics.
If you’ve ever engaged in flame wars about abortion, brexit, Scottish independence, the Ukraine war, the Gaza war, etc, there is a really good chance there were many participants from one of those parties.
This may or may not be useful. How all this works is beyond my knowledge ..
Naturally, we made it so that 1% of the requests to a forum we ran at the time displayed it to the viewer. :)
IP addresses are expensive if you're not the US. Also they might be reusing a standard corporate filtering product that expects to be deployed on a private network (and in a way, that's what the Iranian internet is).
I really want to know what's on the webpage for the iframe.
Standard DPI firewalls can do that for you. Absolutely no issue.
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.
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...
Fuck this shit, I’m moving to a hovel in the woods.
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.
I feel this only make the fact that tapping calls without confirmation more annoying though.
I don't recall doing anything special to make this happen, but I wouldn't put it past me.
Agreed, now that I remember the self-training I had to do to avoid the issue, this is an obnoxiously awkward design choice!
Look like I've got about two years of James Cage White story arcs to check in on.
> Nitter is a free and open source alternative Twitter front-end focused on privacy and performance.
Where is the mission statement about wanting X gone?
> then I ask: what does X gain from your clicks?
https://news.ycombinator.com/item?id=46100703
> Worst that can happen is they waste resources showing you ads that you don't click on.
https://news.ycombinator.com/item?id=46100744
Almost like you are engaging in entirely bad faith.
