ClientAuth Certificates Everywhere: When Your CA Becomes The Attack Surface - Ben Lintern

Client author certificates everywhere when your C8 becomes the attack surface. Uh quick page about me. I'm a senior cyber security engineer at Pastream. I'm passionate about security architecture, networking, cloud computing and a few other things. So client authentication certificates what are they? So certificates or in this context digital certificates are files used to verify the integrity and or the identity of something. So as an example when you open your phone and go to google.com your brow the well google.com is presenting a certificate that proves it is actually Google and it's not being impersonated. The certificate is signed by a certificate authority that most browsers and operating systems agree it's trusted. Uh the and there's your example. So the

type of certificate I've just used as an example is signed for server authentication. However, certificates can also be signed for client authentication which is the topic of today's talk. So client authentication certificates are usually signed by a trusted certificate authority or CA. Uh yeah and they can be used to establish connectivity uh amongst other things. And in most enterprise implementations, these certificates are signed by an internal CA as opposed to a publicly trusted one. And certificates are typically preferred over usernames and passwords due to the fact that users can't set bad passwords. A certificate can't be fished in the same way that a password can be and also it can be a more seamless experience as

users can't forget a pass where they can't forget a certificate like they can forget a password. Uh just a bit more about whether used in an enterprise. So they can be used to establish connectivity. So connecting to a VPN or if you're using port-based authentication or certificate based authentication with Wi-Fi, which is what Radius does, uh browsers. So uh to instead of a username and password, uh an internal site can request a client authentication certificate. Uh mutual TLS also uses client authentication. Uh so where normal TLS is used for encryption in transit, mutual TLS also verifies the identities of the client and the server and also databases can use certificates as opposed to usernames and passwords.

So what's the problem with this? Most implementations only verify if the certificate has been signed by a trusted CA. They don't verify whether the certificate was signed for the specific purpose. and enterprises typically use a singular trusted CA. I'm now going to go over some real world examples that show where certificate-based authentication is utilized in the enterprise after reviewing well-known vendor documentation and based on my own experience. So this diagram here you can see a pair to siteVPN uh that's allowing remote users access to the corporate network. This requires a valid client authentication certificate to permit connectivity. But as you can see from the screenshot which is from the Azure portal, all it requires is the

certificate to have been signed by a valid CA. Second example, going back to the internal website that I brought up previously, it only instead of a username and password, it requires a valid certificate signed by the CA. And that's what it would look like in engine X. So, uh, the engine X software, in case you're not aware, is the proxy software. And the third line down, SSL client certificate is just verifying whether they whether the certificate has been signed by the CA. Uh, yeah. And the last example there. So, this is a database server with an example user created. And the example apps or workloads uh use a certificate as opposed to a username and password.

But the certificate being presented just needs to be valid, just needs to be signed by the CA as opposed to being signed for a specific user. And that's a screenshot from Postgress. So, if we take a step back, we've got a corporate network that's using certificates for authentication, but all of these services only require a certificate to be signed by the CA. So, if one of the client authentication certificates was compromised, the attacker could authenticate to each of the individual services, even though that wasn't the intended purpose. How do we fix this? So before we go on to how to completely mitigate the issue, first of all, it highlights how important network segmentation is. If we

had a flat network, the attacker could very easily go from service to service compromising them all. Where if we had a segmented network, it'd be a lot harder. But also, we need to be ensuring that certificates are only signed for their specific purpose. If we've got a website that only only needs to do server authentication, we shouldn't also be signing in for client authentication. Uh it's a problem in a lot of certificate templates both for internal and public/external services. Picked on ex I picked on Instagram as an example here, but it's a problem with a lot of sites. But the real risk, the real way to mitigate this issue is we need to have different issuing/intermediate

CAS per service. and the services must be verifying the issuing CA versus the root CA. So going back to the previous example, we'd need to have a different CA for the proxy in the web app, a different one for the database, a different one for the console cluster, which was my mutual TLS example, and a different one for the VPN. And whilst Windows CA only supports one certificate, so you can't have a CA that has multiple issuing CAS, uh I've used Hashi Vault as an example here where you can have multiple different uh certificate authorities uh in the same instance. So you could have this on one VM versus a Windows CA where you need to have a VM per CA.

That makes sense. So, uh, to summarize, most certificate-based authentication implementations only verify if the certificate has been validly signed rather than confirming the full trust context. Enterprises often overlook implicit trust boundaries when deploying certificate-based off and should carefully assess these risks during implementation, but I have picked on certificate-based authentication a lot here. It is still generally more secure when done correctly. And that's my LinkedIn. Any questions?

I was going to say any questions apart from Scott, but you know, I'll let you have it. >> Do you agree with removing client or EKUs from public TLS like we're seeing across the the public industry now? Yeah. So, I know I think it was SSL.com that uh made a post around June or July saying that they're going to be removing them. Yes. If there's no reason to have it uh if if there's no reason for a certificate to be authorized for client authentication, it shouldn't therefore be issued. It shouldn't be signed for that.

>> I'll start at the front and then pass that. >> Um slightly same topic. Uh what's your experience about trust stores? So um servers having trusting CAS that should not be there. Is there any insights that you can share from an enterprise point of view? So I don't know the database service trusts outdated CAS and stuff like that. Uh well I mean if if a service doesn't need to trust any certificate signed by the CA then I guess you know best practice will be to remove it. But I think in with the examples I gave it you are specifying one CA as opposed to trusting all of the CAS that the operating system trusts. I think yeah

>> it's just hard to manage at scale. That's what I want. There there's definitely an administrator >> question out there that you're aware of maybe >> I'm sorry I don't really understand the question. >> Sorry. >> No, it's okay.

uh for speaking to the scale of thousands of internal enterprise certificates and managing trust stores. If uh only way is automation and pulling in my opinion uh even as simple as some of the teams I look after just have used anible to manage the root stores across say cassander clusters and stuff like that. um at least answering that on that side answer will be one example but I mean use your infrastructure configuration tool of choice is what we've had to do in some cases when we have uh a limited ability to customize uh internal CAS of choice to uh the speaker Ben um to Ben um so you were saying that you recommend uh intermediate CA differentiating by

purpose and by service and so on which is obviously also um a degree of infrastructure that needs to manage you need to manage especially if the number of services you support for internal CAS is exponential. Um what have you looked into any options of instead of uh delineating services by CA intermediate CA or not using uh attributes in the certificate other than purpose >> and if so what flaws or benefits have you seen in that approach? So I I guess the point I've been trying to make is that most implementations of certificate-based authentication don't check attributes. They don't check you know common names. They are just checking whether it's been signed by the CA. So, uh, you know, the

ideally all services would be checking common names and they'd say, "Oh, these users, if this certificates been issued for Ben Linton, you know, we'd have a list that says Ben Linton's authorized for this." But, I guess the point I've been trying to make is it is not done at all. Yeah. Can we get my steps in? Uh, I can give you a bit of history on that one because I did a bunch of dev work uh with OpenSSL, I don't know, 15 years ago. It just didn't it just didn't work. That's why nobody did it. It just didn't work.

>> Any other questions at all? No. In that case, thank you very much indeed, Ben. Cheers.