Remember this lock means the "line is secure." It doesn't tell you anything about the website, how they use your data, how they store your passwords, your data, their privacy policy, none of that.
It also only covers the first hop of the connection. For example, many sites use Cloudflare without authenticated encryption from Cloudflare to their origin server. I'm curious about the statics on origin server encryption. How many sites use their Strict SSL configuration?
They call encryption without authentication the "Full" encryption mode, but it doesn't defend against active attacks, only passive monitoring. There's also a mode for not encrypting the connection at all. Since so many sites use Cloudflare, % of sites using TLS is misleading.
Probably similar issues with other reverse proxy services. It gives users the impression that the connection to the site is secure when only the first hop is secure.
It's part of their business model for sites to use it for TLS without actually setting up TLS on their servers.
One more reason why browsers moving to marking insecure connections as insecure rather than marking seemingly secure connections as secure is a nice change. Especially now that TLS *for the first hop* is the norm (not convinced the situation is as good as it appears due to this).
I get what you're saying, but nope! "the first hop" would be between your device & the local network router.
Encryption exists between your device & the IP address of the destination as resolved by DNS. How the "internal" network is configured from that point on is out of scope.
I'm clearly not talking about packet routing but rather load balancers / reverse proxies terminating TLS connections. I'm not talking about it as the first hop in a packet routing context. I also don't need someone to repeat what I wrote to me as if they're explaining something.
> Encryption exists between your device & the IP address of the destination as resolved by DNS.
TLS is an application layer protocol. The encryption is between an application and a server terminating the connection. It doesn't have to terminate at the initial resolved host.
Cloudflare terminates the TLS connection so that they can cache and modify headers / data as it passes through.
The whole point of my tweets was that this TLS connection is often only a first hop to a load balancer / reverse proxy sending the traffic over the internet again.
And the point of my tweet was to highlight that as a sweeping generalisation with virtually zero basis in fact - just having a pop at cloudflare because that seems to be what people do these days.
It's completely based in fact, is not a generalization and you went out of the way to misinterpret what I said and then explain what I wrote (incorrectly) to me.
TLS is an application layer protocol. I'm not talking about TCP/IP routing. Is your intent just to cause disruption?
I was not talking specifically about Cloudflare. It was given as a nice example. I have no clue what generalization you think I'm making or how what I said is not based in fact.
The word hop doesn't just mean a TCP/IP routing hop. The context matters. I'm not talking about that.
I'm not talking about routing ether & you know it. You're just highlighting it to try and draw focus away from your veiled attempt at cloudflare bashing.
If you're not spreading FUD & it's all based in facts, then why are you "curious about statistics"?
I replied to this thread to add another caveat about TLS termination at reverse proxies / load balancers. What I wrote is relevant the initial tweet and accurate.
I think multiple people reading this would be similarly curious about configuration of CF origin server connections.