Since version 5.68, when stunnel is configured with verifyPeer=yes, CApath=/path and CAfile=/path/file, the 'Acceptable client certificate CA names' and required certificates are displayed during SSL handshaking.
Is it possible to hide this information?
Hi,
On 10. Nov 2024, at 13:47, hshh hunreal+stunnel@gmail.com wrote:
Since version 5.68, when stunnel is configured with verifyPeer=yes, CApath=/path and CAfile=/path/file, the 'Acceptable client certificate CA names' and required certificates are displayed during SSL handshaking. Is it possible to hide this information?
This is https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4, sent by the TLS server in the CertificateRequest message, see https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2.
OpenSSL populates this based on the arguments to SSL_CTX_set_client_CA_list(3), see https://docs.openssl.org/master/man3/SSL_set_client_CA_list/ for docs.
stunnel calls this in https://github.com/mtrojnar/stunnel/blob/master/src/verify.c#L134. As you’ll be able to see from the code paths leading to this call, there is no way to avoid invoking this function in server mode at the moment.
This behavior hasn’t really changed, though — stunnel has previously populated this list, too, see for example https://github.com/mtrojnar/stunnel/blob/stunnel-5.65/src/verify.c#L84. The recent change is that it now includes certificates from CApath.
You should typically not include details that require hiding in the distinguished names of your acceptable CA certificates, though. In other words, you should not need to hide this information.
HTH, Clemens
Hi,
For specific reasons, I cannot use CRLs and have to use CApath to verify peer certificates. These certificates are not CAs and now leak the CN of all certificates.
I think when specifying both CAfile and CApath, 'Acceptable client certificate CA names' only needs to have CAfile.
On Mon, Nov 11, 2024 at 7:41 PM Clemens Lang cllang@redhat.com wrote:
Hi,
On 10. Nov 2024, at 13:47, hshh hunreal+stunnel@gmail.com wrote:
Since version 5.68, when stunnel is configured with verifyPeer=yes,
CApath=/path and CAfile=/path/file, the 'Acceptable client certificate CA names' and required certificates are displayed during SSL handshaking.
Is it possible to hide this information?
This is https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4, sent by the TLS server in the CertificateRequest message, see https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2.
OpenSSL populates this based on the arguments to SSL_CTX_set_client_CA_list(3), see https://docs.openssl.org/master/man3/SSL_set_client_CA_list/ for docs.
stunnel calls this in https://github.com/mtrojnar/stunnel/blob/master/src/verify.c#L134. As you’ll be able to see from the code paths leading to this call, there is no way to avoid invoking this function in server mode at the moment.
This behavior hasn’t really changed, though — stunnel has previously populated this list, too, see for example https://github.com/mtrojnar/stunnel/blob/stunnel-5.65/src/verify.c#L84. The recent change is that it now includes certificates from CApath.
You should typically not include details that require hiding in the distinguished names of your acceptable CA certificates, though. In other words, you should not need to hide this information.
HTH, Clemens -- Clemens Lang RHEL Crypto Team Red Hat
On 11.11.24 17:47, hshh wrote:
For specific reasons, I cannot use CRLs and have to use CApath to verify peer certificates. These certificates are not CAs and now leak the CN of all certificates.
In other words, you effectively maintain a whitelist of *client* certificates that shall be allowed to connect? Are those self-signed, or just issued by an effectively defunct (since it apparently doesn't maintain its CRL anymore) CA?
I think when specifying both CAfile and CApath, 'Acceptable client certificate CA names' only needs to have CAfile.
Your problem is not CAfile vs. CApath but that TLS's way of a server telling the client "you'll have to show me a client cert" goes on to say "... and to pick one in your cert store that I'll accept, note that I'll insist on it to have been issued by one of *these* [explicit list] CAs [or *possibly* it being one of the listed ones *itself*, though I'm tempted to call it a bug if that works]". Even if the server could somehow be made to accept more CAs than it announces, chances are that you'd have to write your own *client* to have it even *try* a client cert that the server's list doesn't label as promising.
Kind regards,
Yes, I need the "whitelist of client certificates" functionality. Currently, I can do this through CApath.
On Tue, Nov 12, 2024 at 8:12 PM Jochen Bern Jochen.Bern@binect.de wrote:
On 11.11.24 17:47, hshh wrote:
For specific reasons, I cannot use CRLs and have to use CApath to verify peer certificates. These certificates are not CAs and now leak the CN of all certificates.
In other words, you effectively maintain a whitelist of *client* certificates that shall be allowed to connect? Are those self-signed, or just issued by an effectively defunct (since it apparently doesn't maintain its CRL anymore) CA?
I think when specifying both CAfile and CApath, 'Acceptable client certificate CA names' only needs to have CAfile.
Your problem is not CAfile vs. CApath but that TLS's way of a server telling the client "you'll have to show me a client cert" goes on to say "... and to pick one in your cert store that I'll accept, note that I'll insist on it to have been issued by one of *these* [explicit list] CAs [or *possibly* it being one of the listed ones *itself*, though I'm tempted to call it a bug if that works]". Even if the server could somehow be made to accept more CAs than it announces, chances are that you'd have to write your own *client* to have it even *try* a client cert that the server's list doesn't label as promising.
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH _______________________________________________ stunnel-users mailing list -- stunnel-users@stunnel.org To unsubscribe send an email to stunnel-users-leave@stunnel.org
-
Clemens Lang -
hshh -
Jochen Bern