Validating Client Certificates

Michael Wojcik mwojcik at opentext.com
Tue Mar 19 13:12:57 UTC 2024


> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
> Martin Bonner via openssl-users
> Sent: Tuesday, 19 March, 2024 02:21
> 
> > Date: Thu, 14 Mar 2024 13:30:13 +0000
> > From: Michael Wojcik <mailto:mwojcik at opentext.com>
> 
> > Using client certificates might be a step in improving the strength of the authentication
> > mechanism, but they don't do so inherently.
> 
> But depending on the application, it may be a very a very significant improvement. 

Sure, it *might* be. It depends on your threat model.

> If the server is remote from the client and uses passwords, an attacker can try to login by
> guessing usernames and passwords.

Most of my customers are running on private networks, where even an attacker with network access to the server generally has better attacks available against client credentials and impersonation (e.g. SMB pass-the-hash opportunities via shared-resource confusion, phishing, etc) than credential-forcing or -stuffing against a server, particularly when measures such as throttling and behavioral detection are enabled (to say nothing of MFA). That's one example of a case where a threat model likely doesn't show much improvement overall from using TLS mutual authentication.

Client certificates introduce PKI and usability issues. Sometimes those costs are worth paying.

Passwords are lousy authenticators. So are all the others. In a given use case, some will be less lousy; but none are universally a better choice.

In any case, this is at best only tangentially related to OpenSSL now.

-- 
Michael Wojcik


More information about the openssl-users mailing list