Is if statement valid for cert client verification ?

[Mik J]

Hello Thomas,

Thank you very much for these detailed explanations.

I did use
    ssl_client_certificate /etc/ssl/certs/myuser.crt;
    ssl_verify_client on;

But I had in mind to remove "ssl_client_certificate /etc/ssl/certs/myuser.crt", and replace it with
if ($ssl_client_s_dn !~ "O=MyCorp") { return 403; }

When I read your explanation, I understand that in this file
  ssl_client_certificate /path/to/client/cert/ca.pem;
=> I would need to concatenate all my individual client certificates ?

I wanted to remove "ssl_client_certificate /etc/ssl/certs/myuser.crt" because I wanted that client verification would work for myuser1, myuser2....not juste for one user.
Basicly for all my users in my company, and the website would be exposed on the internet.


Thank you for clarifying the attack scenario, I didn't think about it at all.


My ssl configuration is
    ssl_dhparam /etc/nginx/dhparam4096.key;
    ssl_ecdh_curve prime256v1;
    ssl_certificate /etc/ssl/certs/myapp.mydomain.org_chain.crt;
    ssl_certificate_key /etc/ssl/private/myapp.mydomain.org.key;
    ssl_stapling_verify on;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 180m;
    ssl_client_certificate /etc/ssl/certs/myuser1.crt;
    ssl_verify_client on;


Regards


Le mercredi 12 mars 2025 à 00:35:36 UTC+1, Thomas Ward <teward at ubuntu.com> a écrit : 





Ideally, I would suggest you avoid using `if` for this because there's 
ways your string matching could be bypassed (by providing a client cert 
with your Org defined in the DN but not legitimate), and instead rely on 
issuing of certs by a specific Certificate Authority and validate 
against that, ala:

server {
  listen 443 ssl;
  ...
  ssl_client_certificate /path/to/client/cert/ca.pem;
  ssl_verify_client on;
  ...
}

This will reject anyone who doesn't have a valid client certificate 
created by the CA defined in ssl_client_certificate. Explanation of my 
issues with YOUR approach (as you don't specify if you're doing 
ssl_client_certificate or ssl_verify_client on;) is assuming you aren't 
doing this, and there's a detailed explanation of why your solution is bad.

---

The way YOU'VE suggested is unsafe and opens to MITM or certificate 
faking. Let's use the following example.

My site accepts client certificates. The CA chain is:

CN=Spigot-CA,OU=Technical,O=Spigot,C=US (Serial 69D2DC9DAAABD023)
--> CN=teward,OU=Admin,O=Spigot (Serial 575EDDCAAA0D654F)

I am using your if statement, matching any case where O(rg) is not equal 
to Spigot. However, I am not actually validating the certificate 
signature against the CA cert. As part of Red Team exercises, the red 
team makes a new certificate that has no CA chain and is self-signed 
with the following DN:

(SELFSIGNED) CN=joesmith,OU=badguy,O=Spigot

When the `if` gets triggered and the ssl_client_certificiate isn't set 
and ssl_verify_client not set to "on", then when your if statement reads 
the DN of the Red Team's certificate, it will not ever hit the 443, 
instead it'll be seen as a "legitimate" cert and processing continues. 
That opens you up to "spoofing" of certificates to bypass protections.

Red Team notifies the security team (me) about this vulnerability. So I 
enforce CA cert checks and client verification.  By forcing the 
verification instead of the CA's certificate against the Client 
Certificate presented (which does cryptographic signature tests, etc. 
far beyond just checking the DN of a certificate), it will prevent that 
'spoofed' cert from working.

Accordingly, when I ask Red Team to retest with the permissions set 
accordingly to actually validate the cert against a specific CA cert or 
chain of certs, the Red Team can no longer succeed with their 'spoofed 
certificates' approach, and would need a valid client certificate signed 
by the valid CA certificate (which requires them to have the private 
key, which if you handle data right will never happen) to access the 
site or its resources (and simply would get Bad Request or similar 
because they didn't send a proper SSL cert).

---

Unless I'm misunderstanding your intention, which may be possible 
because you don't include your whole example configuration, etc. for 
this use case.


Thomas

On 2025-03-11 18:58, Mik J via nginx wrote:
> Hello,
>
> I remember from Nginx that "if" can be evil.
>
> I would like to validate that if can be used in the a context where I would like to authenticate my clients with a certificate.
>
> if ($ssl_client_s_dn !~ "O=MyCorp") { return 403; }
>
> Do you have any recommendation ?
>
> Thank you
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx