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?
Because having a connection that's encrypted between a user and Cloudflare, then unencrypted between Cloudflare and your server is often better than unencrypted all the way. Sketchy ISPs could insert/replace ads, and anyone hosting a free wifi hotspot could learn things your users wouldn't want them to know (e.g. their address if they order a delivery).
Setting up TLS properly on your server is harder than using Cloudflare (disclaimer: I have not used Cloudflare, though I have sorted out a certificate for an https server).
The problem is that users can't tell if their connection is encrypted all the way to your server. Visiting an https url might lead someone to assume that no-one can eavesdrop on their connection by tapping a cross-ocean cable (TLS can deliver this property). Cloudflare breaks that assumption.
Cloudflare's marketing on this is deceptive: https://www.cloudflare.com/application-services/products/ssl... says "TLS ensures data passing between users and servers is encrypted". This is true, but the servers it's talking about are Cloudflare's, not the website owner's.
Going through to "compare plans", the description of "Universal SSL Certificate" says "If you do not currently use SSL, Cloudflare can provide you with SSL capabilities — no configuration required." This could mislead users and server operators into thinking that they are more secure than they actually are. You cannot get the full benefits of TLS without a private key on your web server.
Despite this, I would guess that Cloudflare's "encryption remover" improves security compared to a world where Cloudflare did not offer this. I might feel differently about this if I knew more about people who interact with traffic between Cloudflare's servers and the servers of Cloudflare's customers.
This is probably technically true, but setting up TLS properly on your server is really ridiculously simple.
Let's encrypt and ACME hasn't always been available. Lots of companies also use appliances for the reverse proxy/Ingress.
If they don't support ACME, it's actually quite the chore to do - at least it was the last time I had to before acme was a thing (which is admittedly over 10 yrs ago)
1. Because TLS certificates were not free
2. Because firewall was "enough" in most people's minds
3. Because TLS was the most CPU intensive part of serving a static site
4. Because some people were using cheap shared hosting providers that upcharged for TLS
I pick it whenever I don't want to setup HTTPS on my origin but still want HTTPS. Just for projects where I really don't care.
</Irony>
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.
The sky is purple! Charlie Brown had hoes! Cloudflare invented Let's Encrypt! Just say anything you want! We live in a post-truth world- there's no need for anything you say to correspond to any external reality!
you must be new to the internet...
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.
For work, I used to use certbot directly at my old place. Now I am building my new stuff on k8s, and I have the ingress manage my certs for me (likely using certbot or similar behind the scenes). Both have been extremely low setup effort and no ongoing effort.
I don't like giving Cloudflare my (or my companies/customers) data in exchange for being able to click a checkbox.
What a deal.
You changed the subject btw.
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
Edit: I don't see any "machine name" on crt.sh for public LB which uses LE
Ah, you meant the DNS address is on CT now. You think I wouldn't know that? Regardless, a dns01 challenge is far better than using self-signed at home
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 ..
It's behind CF
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.
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).
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.
Some apps seem to call some "make a phone call now" API, and that opens a modal pop-up with exactly two options – make the call or don't.
One workaround is to take a screenshot of the number being displayed, but... Come on, Apple.
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.
-Iran