[HN Gopher] Cloudflare Introduces Automatic SSL/TLS
___________________________________________________________________
Cloudflare Introduces Automatic SSL/TLS
Author : bo0tzz
Score : 47 points
Date : 2024-08-08 16:44 UTC (6 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| LinuxBender wrote:
| 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.
| ashconnor wrote:
| ECH _TLS Encrypted Client Hello_ -
| https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08
|
| https://blog.cloudflare.com/encrypted-client-hello
| alberth wrote:
| 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.
| LEisthereason wrote:
| >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?
| javawizard wrote:
| 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...
| prdonahue wrote:
| 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).
| supriyo-biswas wrote:
| 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.
| SparkyMcUnicorn wrote:
| 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.
| chedabob wrote:
| I'm not that experienced with CF, but I believe you can do this
| with Origin rules.
| amluto wrote:
| 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.
| biomcgary wrote:
| Am I misreading the architecture diagrams or is this going to be
| the largest MITM scenario in history?
| creatonez wrote:
| 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.
| xyzzy123 wrote:
| 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)
| mxs_ wrote:
| obligatory: https://encrypted-
| tbn0.gstatic.com/images?q=tbn:ANd9GcQyItWM...
| moralestapia wrote:
| Context for that?
___________________________________________________________________
(page generated 2024-08-08 23:02 UTC)