Why does the title say "Zero Trust", when the article explains that this only works as long as every involved component of the Cloudflare MitM keylogger and its CA can be trusted?
If hosts keys are worthless because you do not know in advance what key the proxy will have.. than this scheme is back to trusting servers merely because they are in Cloudflare address space, no?
Every zero trust architecture ends up trusting an unbounded set of machines. Like most marketing terms, it’s probably easier to assume it does the inverse of what it claims.
My mental model:
With 1 trust (the default) any trusted machine with credentials is provided access and therefore gets one unit of access. With 2-trust, we’d need at least units of trust, so two machines. Equivalently, each credential-bearing machine is half trusted (think ssh bastion hosts or 2FA / mobikeys for 2 trust).
This generalizes to 1/N, so for zero trust, we place 1/0 = infinite units of trust in every machine that has a credential. In other words, if we provision any one machine for access, we necessarily provision an unbounded number of other machines for the same level of access.
As snarky as this math is, I’ve yet to see a more accurate formulation of what zero trust architectures actually provide.
I think your model is absolutely right. But there's a catch: Zero Trust (TM) is about not giving any machine any particular kind of access. So it's an infinite amount of machines with zero access.
The point of Zero Trust (TM) is to authenticate and authorize the human being behind the machine, not the machine itself.
(Clearly, that doesn't work for all kinds of automated access and it comes with a lot of question in terms of implementation details (E.g., do we trust the 2FA device?) but that's the gist.)
That's not the intention of zero-trust. As others have said, it's about authenticating the user and associated privilege, not the machine itself. Simply put, zero trust means machines on the intranet must undergo a user-centric authentication and authorization step prior to accessing any resource. Additionally, once authenticated, a distinct secure channel can be established between the specific endpoint and the resource that cannot be observed or manipulated by others on the same network.
In my view the eventual goal of security is to reduce all excess trust to zero. Excess trust is all trust which is not fundamental to thing you are trying to do. If you want a feature that let's Alice update policy, you need to trust Alice to update policy. I believe that a system without any excess trust is worth building that's why I founded BastionZero and why I joined Cloudflare to work on this.
Getting there is a long walk through the woods on a moonless night.
> With 2-trust, we’d need at least units of trust, so two machines. Equivalently, each credential-bearing machine is half trusted (think ssh bastion hosts or 2FA / mobikeys for 2 trust).
You might be interested in OpenPubkey[0, 1] which was developed at BastionZero. It has 1/2 trust for OpenIDConnect and can be used for SSH.
> As snarky as this math is, I’ve yet to see a more accurate formulation of what zero trust architectures actually provide.
I prefer the term epsilon-trust to reflect the nature of security and trust reduction as an iterative process. The trust in a system approaches but never fully reaches zero.
Zero Trust just means you stop inherently trusting your private network and verify every user/device/request regardless. If you opt in to using Cloudflare to do this then it requires running Cloudflare software.
Thats one interpretation... ZT also posits assuming the network is compromised and hostile, that also applies to CF and their cloud/network. It blows my mind that so many solutions claim ZT while mandating TLS to their infra/cloud, you can trust their decryption of your date, and worst IMHO, they will MITM your OICD/SAML key to ensure the endpoint can authenticate and access services... that is a hell of a lot of implicit trust in them, not least of them being served a court order to decrypt your data.
Zero trust done correctly done not have those same drawbacks.
Zero Trust means you stop trusting your private network, and start trusting Cloudflare, and installing their special root certificate so they can MITM all your web traffic. To keep you safe.
Technically I guess that's "zero trust" in the sense of meeting the requirement of not trusting internal connections more than external ones, but in practice I guess "zero trust" also typically entails making every connection go through the same user-based authentication system, which uploading specific keys to specific servers manually definitely doesn't achieve.
Question. Not specifically for you, but related to this comment.
Would this mean that a PostgreSQL listening on localhost and always asking for user and password is considered Zero Trust, but peer authentication is not?
This part is always a bit confusing for me because there's already been authentication (OS login) creating a session for a specific user (OS user) accessing a specific service (through a unix domain socket) with the specific connection being validated (the unix domain socket permissions).
And from my limited knowledge, the OS login looks like an IdP (Identity Provider), the OS session looks like a JWT already validated by a middleware (the OS vs some API Gateway), connecting to a service using this "token" (OS session vs JWT), and only allowing access to this specific connection (the connection to the socket) if the token is valid (OS session has permissions vs JWT has good signature) and has permissions to the application itself (PostgreSQL checking the connecting user has access to this resource vs the application checking the connecting user has access to this resource).
So I can see this as Zero Trust because the pattern is kinda matching ("the letter"), but also as Not Zero Trust because I feel like this would still be considered a "trusted context" by what the term tries to convey ("the spirit").
> Why does the title say "Zero Trust", when the article explains that this only works as long as every involved component of the Cloudflare MitM keylogger and its CA can be trusted?
The truth-yness of "zero trust" really depends on who's trusting who.
Different responder, but I imagine they are referring to CloudFlare's stated ability to:
Provide command logs and session recordings to allow administrators to audit and replay their developers’ interactions with the organization’s infrastructure.
The only way they can do this is if they record and store the session text, effectively a keylogger between you and the machine you are SSH'ing into.
Keylogger has a specific meaning which doesn’t refer to audit logging. Trying to scare people by misusing loaded terms has the opposite effect from what you intend.
Keyloggers are absolutely used for audit logging. I've implemented these MiTM patterns specifically so we could log all keystrokes. The addition of a keylogger is only an issue if you don't trust Cloudflare, but usually a checklist item for these kinds of bastion hosts in certain compliance environments.
Yes, but it’s not a man in the middle attack when it’s monitoring your own servers any more than it’s a privacy breach when HR looks at your file. My intent was simply that trying to make things sound scary by using language normally used in adversarial contexts really isn’t helpful when talking about things companies need to do. There isn’t an expectation of privacy what what you do on company servers.
I’ll concede that keylogger is sometimes used in a corporate workstation monitoring context but it isn’t really the same as session monitoring on servers. The main thrust of my comment was simply that using loaded language to make common needs sound scary is distracting from rather than helping matters.
I think the original poster's intention was to be somewhat inflammatory as a way to draw attention to the very high level of trust you are granting to CloudFlare in this model. You are effectively giving them whatever privileges you yourself have on those boxes.
Of course, CloudFlare is making it their business to be and convince others that they are that trusted third-party.
In Privilege access management platform (including ours [1]), every operation that a user does is multiplexed via (stdout/stdin) and captured for auditing. This is a compliance requirement for SOX, PCI etc.
