Differentiating server and client in Mutual TLS authentication

Question

When authenticating the client side with a certificate that is also verified by our self-signed ca certificate that verifies server certificate, I think It's possible for clients to perform a MITM attack and order other clients. Maybe I'm wrong but could it be possible? for fixing this problem I can think of these solutions:

1- using username-based authentication instead.

2- using another ca for verifying client.

3- Programming clients in a way that they must use a certificate other than server certificate.

Any ideas?

Edit: I just wanted to point out that I'm using mqtt protocol and ca and client certificate are installed in embedded devices in a local network.

I think I have mixed up authenticating and authorization. – shark Aug 28 '18 at 15:54 — shark, Aug 28 '18 at 15:54

score 3 · Accepted Answer · edited Oct 07 '21 at 08:14

No, it's generally not possible, as long as all the certificates are generated with proper Extended Key Usage (EKU) X.509 field value and all your TLS servers respect RFC.

For a client certificate, EKU should contain the TLS WebClientAuthentication value, and for a server certificate, should contain the TLS Web Server Authentication value. (Note that I'm providing human-readable description of the fields and values, not the actual OID values.)

It is common for certificate authorities to include also TLS Web Client Authentication value in a server certificate, which is not bad in and of itself (at least personally I don't see an attack scenario here), but not vice versa.

Take StackExchange certificate as an example:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication

Also, a server certificate contains the domain name of a server in either the Subject or in the Subject Alternative Name X.509 fields. For StackExchange it looks like this:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        <...>
        X509v3 Subject Alternative Name:
            DNS:*.stackexchange.com, DNS:stackoverflow.com, <...>

Here, the Common Name in the certificate equals to *.stackexchange.com, and Subject contains the Common Name.

Now, to start issuing client certificates, you usually have to come up with a naming scheme, i.e. what you put in the Subject field and the nested Common Name field. How you do that is completely up to you, but better make sure that under no circumstances could a Common Name within a client certificate coincide with a Common Name of one of your domains, in case either your CA or some of the TLS-enhanced applications in your infrastructure do not obey RFC strictly.

A simple way to ensure this is to put the full name of a user into the Common Name and then make sure that each client certificate issued either does contain a space, or doesn't contain a dot. As far as I know, at least one of those two requirements could be satisfied with pretty much any full name which exists in the world.

I disagree with the statement that EKU somehow prevents MITM. Also, you say that clients must not have server auth EKU -- it is incorrect too. In some cases client and server may change roles (like in site-to-site tunnels) and it is normal case when each end has both, client and server EKU. — Crypt32, Aug 29 '18 at 14:14
@Crypt32 the latter case is covered in the answer. And I can't do anything with disagreement if no arguments are provided. — ximaera, Aug 29 '18 at 14:21

score 2 · Answer 2 · answered Aug 28 '18 at 18:21

I think you're mixing together two different concepts that use similar words "verifying" or "validating".

Ordering certificates

This is the process where,

If it's a server, the server admin will create a CSR (certificate signing request) and send that to the CA, or otherwise order a cert.
The people who run the CA (maybe actual humans, maybe automated) will verify the details in the CSR, ie if you're requesting a certificate for www.mysite.com, do you actually own www.mysite.com? If you're requesting a client cert for nickii@mysite.com, are you actually that user? etc.

It's definitely possible to fool a CA into giving you a certificate that you shouldn't have, but usually you don't use the word "man-in-the-middle" here, you would instead say "issuing a fraudulent certificate".

You haven't told us how your servers and clients order certificates from your self-signed CA, but I would hope there are some humans looking at and manually approving each request, or some other process to prevent fraudulent certificates from being issued. If clients can order other clients, that would definitely be bad, but there's not enough info in your question to tell if that's possible.

Intercepting web traffic

This is where you'll talk about "man-in-the-middle" attacks, ie where you think you're talking to the real www.mysite.com, but you're actually talking to an attacker who has a fraudulent cert for that site.

You seem to be worried that someone could get a client certificate with the server name in it?

First off, as mentioned above, the human clicking "issue certificate" would notice this kind of trick and not give the certificate.
Second, a client certificate should not be able to act as a server. CAs will put in a field called Extended Key Usage (EKU) or Enhanced Key Usage that tells whether this certificate is a client or a server or both. You should make sure that your CA is including this in the certificates that it issues, and that your clients are checking for the Server EKU before accepting the connection.

I've actually seen a CA once which used to check in both `serverAuth` and `clientAuth` (and also `codeSigning`) EKU values for all the client certs issued. Also, we can only hope that all the servers and libraries in @nickii's network are up to date. — ximaera, Aug 28 '18 at 18:31
@ximaera That sounds like bad practice ... I hope that wasn't a publicly-trusted CA. — Mike Ounsworth, Aug 28 '18 at 18:45

score 1 · Answer 3 · answered Aug 28 '18 at 17:56

As long as all certificates are unique (no single certificate is shared between two or more entities) and root CA is trusted there is no way for MITM.

That is, server and each client must have its own unique certificate and only certificate owner possesses the private key. Also, configure server to validate certificates issued by your own CA and only your CA is authorized to issue client authentication certificates. These are certificate-based authentication basics. Of course, you have to implement proper CA operations to avoid certificate mis-issuance, develop revocation procedures and so on.

Additionally, you may need a database with clients and map certificate to client account for auditing and permission purposes. Server may use this information to apply restrictions to clients.

score 0 · Answer 4 · answered Jun 29 '21 at 21:55

The accepted answer is correct in general. Note however that in some cases, this might not be true.

For example, if you use the same CA for generating client and server certs for OpenVPN, you might be vulnerable: a client might use its keypair to impersonate the server in the default configuration.

This is because the following in the default configuration, the client does not verifiy the Key Usage (KU) and Extended Key Usage (EKU). Moreover, it does not check that the target hostname matched with the host names in the remote certificate.

The clients should use:

remote-cert-tls server

Note: this assumes that the generated certificates actually include the KE and EKE extensions.

Reference:

This is a useful security option for clients, to ensure that the host they connect to is a designated server. [...] This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --remote-cert-tls, --verify-x509-name, or --tls-verify.

As you usually cannot be certain that all your clients will use the correct configuration, I'd recommend using different CA for client and for servers certificates for OpenVPN.

For reference, here's the default configuration when configuring a OpenVPN instance through NetworkManager:

You can see that the verification is disabled by default.

Differentiating server and client in Mutual TLS authentication

4 Answers4

Ordering certificates

Intercepting web traffic