Cloudflare Introduces Automatic SSL/TLS | Hacker News Reader

Cloudflare Introduces Automatic SSL/TLS

blog.cloudflare.com

61 pointsbo0tzz21 comments

Cloudflare is talking about the security benefits of Cloudflare Tunnels. They may well be fairly secure, but I would love to see Cloudflare clean up their configuration system so that the configuration actually matches the behavior.

Setting up a mapping from DNS name to route should not be called DNS and should absolutely not pretend to be a CNAME. The mapping from origin-side route to tunnel should not be done by pretending that a tunnel has a domain name. The routes should not be apparently separately configured in at least three places (DNS, Tunnel, and and Access). The JWT verification feature of tunnels should document what it does, and whatever it does should make sense and be well integrated with everything else. The Access settings should make sense, should not magically create other config, and the security settings should not require creating named groups that have entirely unclear scoping.

And for Pete’s sake, get rid of the bizarre config split between Zero Trust and everything else. It makes no sense and appears to just involve pointlessly reloading the config SPA because I guess Zero Trust uses a separate SPA that merely pretends like it’s the same one as everything else.

Completely agree with all this. It’s getting worse over time too.

This sort of thing is frustrating from a company that seems to launch a new product every week.

The Zero Trust portal is such a terrible experience to use and has felt very badly “bolted on” to the rest of the Cloudflare portal from the beginning and has only continued to diverge from there.

Cloudflare’s usability took a huge dive for me when tunnels moved out of the main UI.

The integration between critical security products is poor too (eg Access and Tunnels) leading to confusion and uncertainty - which is exactly what you don’t need when it comes to security.

I used to happily accept the MITM downsides for the benefits that CF brings but I’m getting quite close to writing my own simple managed reverse proxy system based on Nginx and just focusing on a few core features that I need.

Since this takes human operations out of the loop on the origin for certs I could see an opportunity to add one more privacy step until ECH is universally supported on all the things. Their origin side daemon could sign a cert with a name that Cloudflare trusts but does not in any way match the domains on the origin server. Thus anyone intercepting traffic can not tell via ESNI handshake what domains that origin server is serving. The translation to the actual domain(s) could occur on the origin side. Alternatively their daemon could configure Wireguard so that all traffic is encapsulated in a VPN between Cloudflare and the origin, or perhaps some WAN optimized VPN daemon that can re-route around circuit outages similar to how tinc-vpn can be configured and one of the WAN optimizer daemons that uses FEC and multiple streams.

ECH TLS Encrypted Client Hello - https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08

https://blog.cloudflare.com/encrypted-client-hello

Yes I mentioned ECH. Correct me if I am wrong but none or almost none of the origin servers support it. Openssl, nginx, apache, haproxy, caddy AFAIK do not support it. The flow I am talking about is from Cloudflare to the origin server.

>This worked well and was easy because Cloudflare could manage the certificates and connection security from incoming browsers. As a result of that work, the number of encrypted HTTPS connections on the entire Internet doubled at that time. However, the connections made from Cloudflare to origin servers still required manual configuration of the encryption modes to let Cloudflare know the capabilities of the origin.

Is Cloudflare actually trying to take credit for Let's Encrypt or am I misunderstanding what they're trying to say here?

The work they're talking about in that sentence[0] launched ~2 months before Let's Encrypt was publicly announced, and almost a year before Let's Encrypt signed their first certificate.

So no, this was a separate effort.

[0] https://blog.cloudflare.com/introducing-universal-ssl#:~:tex...

You’re misunderstanding. LE went GA in April 2016 and Cloudflare is talking about ~2 years prior to that (where they used GlobalSign and Comodo, not LE).

Am I misreading the architecture diagrams or is this going to be the largest MITM scenario in history?

Cloudflare's default is to MiTM all traffic and modify it on an HTTP level. If you opt out of this and configure it to connect directly, you are opting out of most of their products (DDoS protection, page rules, etc.)

Is this a huge security problem? Yes, it probably will be, some day. But it is what it is, they don't mislead users about the fact that traffic gets decrypted and re-encrypted.

It already happened once, remember this? https://blog.cloudflare.com/incident-report-on-memory-leak-c...

(Aka CloudBleed https://en.m.wikipedia.org/wiki/Cloudbleed)

The re-encrypted part isn't necessarily true though and you have no way of knowing. Users are misled because they see a nice secure lock icon in the browser, but that only protects the connection to the local Cloudflare POP, the rest of the way to the origin is all vulnerable to MITM.

As a security company, anything less than "Full (Strict)" should not exist.

Cloudflare publishes a certificate pair you can pin to your origin servers.

They also offer CloudflareD (Tunnels, formerly Argo), which connects origin directly to their network- so no chance of interception or Bypassing their services.

So, as long as it's set up correctly- theres no opportunity to MitM between Origin and Cloudflare.

Do people set it up correctly? I doubt it. I've seen several companies think they were using CF's WAF product, when all they really setup was DNS.

obligatory: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQyItWM...

Context for that?

What exactly do you think CDNs do?

Somewhat related to this topic, does Cloudflare have a way to proxy requests for, say, example.com but accept a certificate on the origin with a different hostname, such as origin.example.com without also setting the SSL mode to Full instead of Full (strict)?

This makes it a little bit annoying to deploy applications securely, since any self signed cert would be accepted with this setting as well, which is not what I want as it opens up the possibility of MITM attacks.

Are you essentially asking if there's a way for cloudflare to change the host header?

You can use a worker to proxy things like this, but that's going to live outside of the SSL settings and CF proxy, unless you set up an additional zone for "origin." and proxy apex to that.

I'm not that experienced with CF, but I believe you can do this with Origin rules.

I believe that's an Enterprise feature.

Why hasn't this always existed?

I'm guessing because this topic is a "fractal".

At a high-level, it appears super simple - but the more you zoom in, the more complex it becomes.

Reply on news.ycombinator.com