Cloudflare Access: Like BeyondCorp, but You Don’t Have to Be at Google to Use It | Hacker News Reader

Cloudflare Access: Like BeyondCorp, but You Don’t Have to Be at Google to Use It

blog.cloudflare.com

116 pointsthedg21 comments

> Encrypted: As Cloudflare makes all connections secure with HTTPS there is no need for a VPN.

If Cloudbleed has taught us something, it's that cloudfare idea of "fully encrypted" doesn't fully include what's happening inside their own (virtual) walls.

Some may still consider the way they do it ok for websites. I don't, encryption between my customer and me, not between them and cloudflare, opening their data to another actor they have to trust without even knowing it, especially since most of my customers and myself are in Europe not the USA, so I don't want any US authorities to be able to intercept my stuff through them.

But for your company internal stuff ? I get that most companies don't really get pressured to take good care of users data because leak usually hurt the consumers themselves the most, not them, and they don't get blamed for it much. But surely it's not hard to see how opening your own internals is asking for troubles ...

You give all access to cloudflare, you give all access to bugs in cloudflare's software (like cloudbleed), you give all access to any authorities with influence over cloudflare, you give all access to hacker who can get inside cloudflare (even if they only get one small opening into where you data comes through), ... And this time it's not your customers' stuff, it's yours (not saying it doesn't matter when it's theirs, but it's easier to dismiss by Mr Bean Counting Project Manager).

If I am wrong in assuming this and the connection is made user to final endpoint without decryption at cloudflare level I couldn't see it when looking at that page.

> If Cloudbleed has taught us something, it's that cloudfare idea of "fully encrypted" doesn't fully include what's happening inside their own (virtual) walls.

I think that's a little unfair. Cloudbleed specifically referred to an application that parsed HTML. There's a pretty big logical dependency between "able to optimize our HTML" and "can see our HTML". I feel like the field of homomorphic encryption and HTML parsing is... non-existent.

I both agree and don't see what it changes in my message. Yes, it's obvious that they need to see it to be able to do several features they offer. Doesn't mean it's a good idea to let them see it.

Trading security for convenience has never really been a good deal, and this new product is about doing it with your company's internal.

For those interested by the idea but who need open source, we've been using https://github.com/bitly/oauth2_proxy for a while with great results.

I have also been using oauth2_proxy to allow users to authenticate via SSO and then access a application. It was easy to deploy and has been painless to manage.

I've never worked at Google but I thought BeyondCorp wasn't just about SSO auth. It included a reputation system, 2FA, and geofencing, among other things. This just looks like a fancy authentication facade with logging.

The BeyondCorp paper is public: https://static.googleusercontent.com/media/research.google.c...

Looks like an MVP to me.

How does this compare to ScaleFT's zero trust web access product? Does Cloudflare do anything special beyond client certs to make authorization decisions after authentication? Seems like an easy pivot and nice accessory on top of argo and warp but there's little to no mention of logic used to detect on-device threats.

I'm with ScaleFT, thanks for the shoutout. We've been huge believers in BeyondCorp since the first paper was released, and have incorporated the concepts into our Web Access product - https://www.scaleft.com/product/web-access

Similarly, apps are placed behind a reverse proxy, which performs authN via your company's IDP, then authZ against the policies associated with the resource. These can be basic RBAC or more device oriented decisions such as whether the client disk is encrypted.

We also believe a SaaS model is the way to make BeyondCorp a reality for companies who aren't Google, but there's more to it than a proxy service. We've found the more challenging aspects of a complete system to be the policy engine and device bindings, and have spent the past couple years working to offer with our product.

Glad to see CloudFlare talking about BeyondCorp, the more who are providing solutions in this space, the easier it will be for companies who are not Google to get there.

Wouldn't this mean granting Cloudflare access to all resources available? Does not sound like a very secure infrastructure concept.

Don't worry, the industry moves so fast that entire generations have come and retired in the 11 months since they last leaked private data all over the Internet

(Don't even get me started on FlexSSL!)

For small companies, this can be a valuable tradeoff. For example, we just secured a background processing service using Cloudflare Access; very practical and without too much security tradeoffs.

Note that there are thousands of certificate authorities that hold the keys to the same resources. The threat is real but difficult to avoid.

Cloudflare also reserves the right to investigate you and your data. See https://www.cloudflare.com/terms/ section 11.

I'd say this goes way beyond the theoretical means of (illegal) access CA might have.

Don't forget about the identity providers you'll rely on - they can also impersonate you.

With more and more corporate applications going to externally hosted SaaS providers, doesn't a service like this become less relevant over time?

Agreed on more workloads going to third party SaaS.

That might obviate a service like this, or else enterprises will want a service like the to broker auth and monitor access to their SaaS as well.

There are CASB (cloud access security broker) products now that do the monitoring and reporting aspect, though AFAIK don't participate in auth.

Almost certainly not because there's usually _something_ inside the corporation and so you then get the need for unified authentication management (e.g. Okta) and some way to access the internal app.

This only works for HTTP, and all systems are not HTTP nor should they be HTTP.

We've gone far, far backward in networked system capability and efficiency by trying to shoehorn all possible uses of a network into a massively overloaded document retrieval protocol.

Stay tuned on non-HTTP. Or if you want to try it early: https://goo.gl/forms/KtzfKYnWhK4SwQP03

Reply on news.ycombinator.com