Questions / SSL_accept errors (soliciting client
Martin Bonner
Martin.Bonner at entrust.com
Wed Apr 10 09:05:10 UTC 2024
>> And finally, but importantly, what exactly is your use case? How does
>> the server expect to benefit from (make access and authorisation
>> decisions based on) client certificates?
> The case is an organization that was initially using passwords
> for authentication. That worked properly and was easy to setup.
> However, in the process of doing that I discovered that all their
> users had the name of the company as their password. ...
> I proposed the certificate authentication and management agreed.
This is off-topic for the OPENSSL list, but it might be worth
reconsidering passwords. A minimum length of 12/15 characters + reject
anything that is known to have been used as a password in the past
(see https://haveibeenpwned.com/Passwords where to get that list),
then strip non-alphabetic characters and reject anything with the
company name as well, would probably be "good enough", and it is a
much less pervasive change than switching to client certificates.
Martin Bonner
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of openssl-users-request at openssl.org
Sent: Wednesday, April 10, 2024 1:36 AM
To: openssl-users at openssl.org
Subject: [EXTERNAL] openssl-users Digest, Vol 113, Issue 6
Send openssl-users mailing list submissions to openssl-users@ openssl. org To subscribe or unsubscribe via the World Wide Web, visit https: //urldefense. com/v3/__https: //mta. openssl. org/mailman/listinfo/openssl-users__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtt7tKjqY$
Send openssl-users mailing list submissions to
mailto:openssl-users at openssl.org
To subscribe or unsubscribe via the World Wide Web, visit
https://urldefense.com/v3/__https://mta.openssl.org/mailman/listinfo/openssl-users__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtt7tKjqY$
or, via email, send a message with subject or body 'help' to
mailto:openssl-users-request at openssl.org
You can reach the person managing the list at
mailto:openssl-users-owner at openssl.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. OpenSSL version 3.3.0 published (OpenSSL)
2. SSL_accept errors (Doug Hardie)
3. Questions (Doug Hardie)
4. Re: Questions / SSL_accept errors (soliciting client
certificates) (Viktor Dukhovni)
5. Re: Questions / SSL_accept errors (soliciting client
certificates) (Doug Hardie)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Apr 2024 12:56:00 +0000
From: OpenSSL <mailto:openssl at openssl.org>
To: mailto:openssl-project at openssl.org, OpenSSL User Support ML
<mailto:openssl-users at openssl.org>, OpenSSL Announce ML
<mailto:openssl-announce at openssl.org>
Subject: OpenSSL version 3.3.0 published
Message-ID: <mailto:ZhU64O8mTQOAQpyT at openssl.org>
Content-Type: text/plain; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
OpenSSL version 3.3.0 released
==============================
OpenSSL - The Open Source toolkit for SSL/TLS
https://urldefense.com/v3/__https://www.openssl.org/__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtXBIVnb0$
The OpenSSL project team is pleased to announce the release of
version 3.3.0 of our open source toolkit for SSL/TLS.
For details of the changes, see the release notes at:
https://urldefense.com/v3/__https://www.openssl.org/news/openssl-3.3-notes.html__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtxQZDyXI$
Specific notes on upgrading to OpenSSL 3.3 from previous versions are
available in the OpenSSL Migration Guide, here:
https://urldefense.com/v3/__https://www.openssl.org/docs/man3.3/man7/migration_guide.html__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtU0Ko0RE$
The OpenSSL 3.3.0 is available for download at these URLs:
* https://urldefense.com/v3/__https://www.openssl.org/source/__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtHWDvDEo$
* https://urldefense.com/v3/__https://github.com/openssl/openssl/releases__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPti5QABDM$
The distribution file name is:
o openssl-3.3.0.tar.gz
Size: 18038030
SHA1 checksum: 34cdf3259fd2af83ab2c92ac30c56f79ff5ad59e
SHA256 checksum: 53e66b043322a606abf0087e7699a0e033a37fa13feb9742df35c3a33b18fb02
The checksums were calculated using the following commands:
openssl sha1 openssl-3.3.0.tar.gz
openssl sha256 openssl-3.3.0.tar.gz
Yours,
The OpenSSL Project Team.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmYVMMIACgkQ2JTizos9
efUa0g/+JfJ/crbeQCXfnhJUHwWcU/CvuxLcE285jXLwziKWsHfzkq3wECsNhltW
Amkpztqa4D9tGL/Ve2UARFoNMRxnxyLyxt2DgnYxtXUcypHLDE4opKOp3CImW3Ex
GadXBZwxbCuiXJnZITs87pEhTCj3mvbv08ayH0RxJqQGs9E1CGOcJtmvdAnRAF3Q
5iZeFkwh+Bi3/4K04HofSjUHG7K9/WwEOZDv0PGwcuKOMXfMx5L9Xq/cPQ4bk/s/
hGf0hxE/R05r2kfQgXVfNem9CafnA5Ts+pAefDQ/IV/wugUZYjazLMXnm5FxbYoP
jsNnGgo8ZL3NbGAm2MEkgj6qL4NKpWqhbcgMavF2Pk9kwK3wsr52K1Monw3MxyWA
CEzP3fpter9PdH2Lvd56nzzgrQsUozEVHrWrz3EiwOsReq+AFy2VoDjofLNoarLr
OCiSeKm00iHUKq10MReC7seYfVKZRLN04mqu2fsdZ/WgHjcnKS2C3HbOq8jlkHFy
dt6UWdED89/X7ohXUxwfyBDRG6VDj89yxGsVXrIWvBhCEekDe4AVaNFqtZDD+hf1
eKuf27ll4UR/DBQdOeuJ68QM/yP0ik3rk1VVUrNkArLXRSrUP1srmy/cd4sUSkLd
BHVl+iY7NwDq6kiZjboRyBhga5l6rxfhD0AejuHJPu31EqqH95c=
=88+B
-----END PGP SIGNATURE-----
------------------------------
Message: 2
Date: Tue, 9 Apr 2024 08:43:39 -0700
From: Doug Hardie <mailto:bc979 at lafn.org>
To: mailto:openssl-users at openssl.org
Subject: SSL_accept errors
Message-ID: <mailto:A0FFBB91-3F64-433E-86C0-4643F1150F4B at sermon-archive.info>
Content-Type: text/plain; charset=us-ascii
I have a server that is "working", but there are several issues with connections. The server requires client certificates. If I use openssl s_client and give it the proper certificate, I see one connection that makes the request and returns the response. There are no errors indicated by the server and the response time is almost instantaneous. All the involved systems are on the same LAN.
However, if I use one of the various clients to make the same request, the results are quite different. There are a number of connections made that fail and then finally they make the proper connection and everything works. The time it takes to get through all of that is quite long - around 5 seconds. The server is recording the following errors from SSL_accept:
Connection 1 - session id context uninitialized
Connection 2 - session id context uninitialized
Connection 3 - sslv3 alert certificate unknown
Connection 4 - sslv3 alert certificate unknown
and then Connection 5 sees the proper client certificate, authenticates and produces output.
How can I figure out what is causing these multiple connections and the resulting errors. I have tcpdump and ssldump output but nothing there gives me any ideas. I can provide either of those if needed, but they are large. Unfortunately I have not figured out how to get ssldump to decode the application data. As best as I can tell, the negotiated cipher cannot be handled by ssldump.
I don't have access to any of the client's source code. The session id in the error messages indicates that perhaps there is something I need to do with establishing sessions, but I haven't found any examples of what that would entail. The clients each have the same 2 client certificates. They ask which one to use, but perhaps they are trying both? However, it doesn't appear that there are any certificates being passed in either direction for the first 4 sessions. I see them in the 5th session.
-- Doug
------------------------------
Message: 3
Date: Tue, 9 Apr 2024 08:44:41 -0700
From: Doug Hardie <mailto:bc979 at lafn.org>
To: Michael Wojcik via openssl-users <mailto:openssl-users at openssl.org>
Subject: Questions
Message-ID: <mailto:A2803C77-2B9A-43E0-BA0A-721BC89A0499 at sermon-archive.info>
Content-Type: text/plain; charset=us-ascii
When using client certificates, how does SSL_accept validate the provided certificate?
If verify_callback is used, is the client certificate validated before the callback is called?
-- Doug
------------------------------
Message: 4
Date: Tue, 9 Apr 2024 13:59:09 -0400
From: Viktor Dukhovni <mailto:openssl-users at dukhovni.org>
To: mailto:openssl-users at openssl.org
Subject: Re: Questions / SSL_accept errors (soliciting client
certificates)
Message-ID: <mailto:ZhWB7Sq3CStLtoev at chardros.imrryr.org>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 09, 2024 at 08:44:41AM -0700, Doug Hardie wrote:
> When using client certificates, how does SSL_accept validate the
> provided certificate?
By building a certificate chain to a local trust-anchor using the
server's configured trust store, and any untrusted intermediate
certificates presented by the remote client.
Note that verification of client certificates DOES NOT typically include
any "identity" checks, rather only the trustworthiness of the chain is
verified. It is up to the server application to perform access control
on the requested resources based on whatever information the server
independently gleams from the certificate during or after the TLS
handshake.
> If verify_callback is used, is the client certificate validated before
> the callback is called?
No, if all goes well, the callbacks (one per chain certificate) are
made *as part of* validation, with the "ok" parameter set to "1" if
there's no (new?) problem to report at the level in question.
If the callback returns a non-zero value, the handshake continues, if
zero it is aborted. A callback that is purely diagnostic should return
the input "ok" value. If the callback wants to either abort an
otherwise "ok" handshake, or ignore a particular problem, it can return
1 under appropriate conditions even if "ok" was zero.
Note that returning "ok" equal to one does not reset the verification
status for the chain, which can be tested, for e.g. success, via:
SSL_get_verify_result(ssl) == X509_V_OK
this works even on resumption, because the original validation status is
part of the saved/resumed session.
The callback can (with great care to not ignore any important error
conditions) reset the validation result for less critical conditions,
but then it is necessary to either abort the handshake on the import
conditions, or save away state that an earlier problem was not
ignorable, and reset the error to that, rather than to X509_V_OK.
See X509_STORE_CTX_set_error(3), but tread cautiously, there be dragons.
On Tue, Apr 09, 2024 at 08:43:39AM -0700, Doug Hardie wrote:
> The server requires client certificates. If I use
> openssl s_client and give it the proper certificate, I see one
> connection that makes the request and returns the response.
The "s_client" application is liberal in what it accepts:
- Without non-default options, the handshake completes (with some
addtional noise) even if the server certificate fails to verufy.
- It presents the specified client certificate even if the server
does not solicit its issuer CA (or ultimate trust anchor) in its
certificate request message, which lists the acceptable CAs.
- There may of course be subtle differences in various extensions
used, the SNI extension may be important, the others typically
less so.
- Your s_client may be dated, and the issue may only manifest with
bleeding edge client capabilities, though again your s_client is
likely not that old (1.1.1, supports TLS 1.3) and you rarely need
more.
Speculatively, the second item is the most likely source of issues.
> However, if I use one of the various clients to make the same request,
> the results are quite different. There are a number of connections
> made that fail and then finally they make the proper connection and
> everything works. The time it takes to get through all of that is
> quite long - around 5 seconds. The server is recording the following
> errors from SSL_accept:
>
> Connection 1 - session id context uninitialized
> Connection 2 - session id context uninitialized
> Connection 3 - sslv3 alert certificate unknown
> Connection 4 - sslv3 alert certificate unknown
Who's sending/receiving the alerts? The server would typically report
*received* alerts, and it is then perhaps the client that is failing to
validate the server certificate, but without a clear context, it is
difficult to say what happened.
As for session id contexts, your server code needs to set one in order
to support resumption properly, one more difference between s_client
and other clients, is that s_client always starts with no saved
sessions.
The Postfix SMTP server has:
/* * The session_id_context identifies the service that created a session. * This information is used to distinguish between multiple TLS-based * servers running on the same server. We use the name of the mail system. */ static const char server_session_id_context[] = "Postfix/TLS";
...
SSL_CTX_set_session_id_context(server_ctx, (void *) &server_session_id_context, sizeof(server_session_id_context));
> and then Connection 5 sees the proper client certificate, authenticates and produces output.
Perhaps the client is no longer attempting resumption?
> How can I figure out what is causing these multiple connections and
> the resulting errors. I have tcpdump and ssldump output but nothing
> there gives me any ideas.
The ssldump software is abandoned, use "tcpdump" + ""tshark", as explained in:
https://urldefense.com/v3/__https://marc.info/?l=postfix-users&m=166005488423800&w=2__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtiZQYfRg$
> I can provide either of those if needed, but they are large.
With "tcpdump", after capturing a bunch of traffic, you extract just a
particular connection of interest, details in the post linked above.
You can then analyse it with "tshark" (same link).
> Unfortunately I have not figured out how to get ssldump to decode the
> application data. As best as I can tell, the negotiated cipher cannot
> be handled by ssldump.
Delete "ssldump" you're better off without it.
> The clients each have the same 2 client certificates. They ask which
> one to use, but perhaps they are trying both?
A given handshake can only try one client certificate as part of the
normal handshake. THere's also post-handshake authenticaiton (PHA) in
TLS 1.3, but you probably don't have server code for that.
That the clients are putting up a dialogue does strengthen the
plausibility of the server's client certificate request being part of
the problem. You may need to carefully tune your server's list of
solicited client CAs. See the docs for SSL_CTX_set_client_CA_list(3).
Less is more (ideally just one if there's only one CA issuing the
desired certificates).
And finally, but importantly, what exactly is your use case? How does
the server expect to benefit from (make access and authorisation
decisions based on) client certificates?
--
Viktor.
------------------------------
Message: 5
Date: Tue, 9 Apr 2024 17:35:53 -0700
From: Doug Hardie <mailto:bc979 at lafn.org>
To: mailto:openssl-users at openssl.org
Subject: Re: Questions / SSL_accept errors (soliciting client
certificates)
Message-ID: <mailto:89DCA32D-14BA-4734-9DCD-D03E4A8FB7F2 at sermon-archive.info>
Content-Type: text/plain; charset="us-ascii"
Attached is the result for the first connection:
Nothing stands out that I can see.
-- Doug
> On Apr 9, 2024, at 10:59, Viktor Dukhovni <mailto:openssl-users at dukhovni.org> wrote:
>
> On Tue, Apr 09, 2024 at 08:44:41AM -0700, Doug Hardie wrote:
>
>> When using client certificates, how does SSL_accept validate the
>> provided certificate?
>
> By building a certificate chain to a local trust-anchor using the
> server's configured trust store, and any untrusted intermediate
> certificates presented by the remote client.
>
> Note that verification of client certificates DOES NOT typically include
> any "identity" checks, rather only the trustworthiness of the chain is
> verified. It is up to the server application to perform access control
> on the requested resources based on whatever information the server
> independently gleams from the certificate during or after the TLS
> handshake.
>
>> If verify_callback is used, is the client certificate validated before
>> the callback is called?
>
> No, if all goes well, the callbacks (one per chain certificate) are
> made *as part of* validation, with the "ok" parameter set to "1" if
> there's no (new?) problem to report at the level in question.
>
> If the callback returns a non-zero value, the handshake continues, if
> zero it is aborted. A callback that is purely diagnostic should return
> the input "ok" value. If the callback wants to either abort an
> otherwise "ok" handshake, or ignore a particular problem, it can return
> 1 under appropriate conditions even if "ok" was zero.
>
> Note that returning "ok" equal to one does not reset the verification
> status for the chain, which can be tested, for e.g. success, via:
>
> SSL_get_verify_result(ssl) == X509_V_OK
>
> this works even on resumption, because the original validation status is
> part of the saved/resumed session.
>
> The callback can (with great care to not ignore any important error
> conditions) reset the validation result for less critical conditions,
> but then it is necessary to either abort the handshake on the import
> conditions, or save away state that an earlier problem was not
> ignorable, and reset the error to that, rather than to X509_V_OK.
>
> See X509_STORE_CTX_set_error(3), but tread cautiously, there be dragons.
Thanks for that explanation. That would probably be helpful to others if it was included somewhere in the openssl documentation.
>
> On Tue, Apr 09, 2024 at 08:43:39AM -0700, Doug Hardie wrote:
>
>> The server requires client certificates. If I use
>> openssl s_client and give it the proper certificate, I see one
>> connection that makes the request and returns the response.
>
> The "s_client" application is liberal in what it accepts:
>
> - Without non-default options, the handshake completes (with some
> addtional noise) even if the server certificate fails to verufy.
>
> - It presents the specified client certificate even if the server
> does not solicit its issuer CA (or ultimate trust anchor) in its
> certificate request message, which lists the acceptable CAs.
>
> - There may of course be subtle differences in various extensions
> used, the SNI extension may be important, the others typically
> less so.
>
> - Your s_client may be dated, and the issue may only manifest with
> bleeding edge client capabilities, though again your s_client is
> likely not that old (1.1.1, supports TLS 1.3) and you rarely need
> more.
>
> Speculatively, the second item is the most likely source of issues.
It should be a fairly new s_client. The client I used for that testing, and for the server is FreeBSD 14.0.
>
>
>> However, if I use one of the various clients to make the same request,
>> the results are quite different. There are a number of connections
>> made that fail and then finally they make the proper connection and
>> everything works. The time it takes to get through all of that is
>> quite long - around 5 seconds. The server is recording the following
>> errors from SSL_accept:
>>
>> Connection 1 - session id context uninitialized
>> Connection 2 - session id context uninitialized
>> Connection 3 - sslv3 alert certificate unknown
>> Connection 4 - sslv3 alert certificate unknown
>
> Who's sending/receiving the alerts? The server would typically report
> *received* alerts, and it is then perhaps the client that is failing to
> validate the server certificate, but without a clear context, it is
> difficult to say what happened.
All of the logging is on the server side. I don't really have any ability to do anything with the clients.
>
> As for session id contexts, your server code needs to set one in order
> to support resumption properly, one more difference between s_client
> and other clients, is that s_client always starts with no saved
> sessions.
>
> The Postfix SMTP server has:
>
> /* * The session_id_context identifies the service that created a session. * This information is used to distinguish between multiple TLS-based * servers running on the same server. We use the name of the mail system. */ static const char server_session_id_context[] = "Postfix/TLS";
> ...
> SSL_CTX_set_session_id_context(server_ctx, (void *) &server_session_id_context, sizeof(server_session_id_context));
I'll have to do that then.
>
>> and then Connection 5 sees the proper client certificate, authenticates and produces output.
>
> Perhaps the client is no longer attempting resumption?
>
>> How can I figure out what is causing these multiple connections and
>> the resulting errors. I have tcpdump and ssldump output but nothing
>> there gives me any ideas.
>
> The ssldump software is abandoned, use "tcpdump" + ""tshark", as explained in:
>
> https://urldefense.com/v3/__https://marc.info/?l=postfix-users&m=166005488423800&w=2__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtiZQYfRg$
Thanks. I have tdump available but had not figured out how to use it.
>
>
>> I can provide either of those if needed, but they are large.
>
>
> With "tcpdump", after capturing a bunch of traffic, you extract just a
> particular connection of interest, details in the post linked above.
> You can then analyse it with "tshark" (same link).
>
>> Unfortunately I have not figured out how to get ssldump to decode the
>> application data. As best as I can tell, the negotiated cipher cannot
>> be handled by ssldump.
>
> Delete "ssldump" you're better off without it.
So I see. It's going away after I send this.
>
>> The clients each have the same 2 client certificates. They ask which
>> one to use, but perhaps they are trying both?
>
> A given handshake can only try one client certificate as part of the
> normal handshake. THere's also post-handshake authenticaiton (PHA) in
> TLS 1.3, but you probably don't have server code for that.
>
> That the clients are putting up a dialogue does strengthen the
> plausibility of the server's client certificate request being part of
> the problem. You may need to carefully tune your server's list of
> solicited client CAs. See the docs for SSL_CTX_set_client_CA_list(3).
> Less is more (ideally just one if there's only one CA issuing the
> desired certificates).
I only have my root certificate in the chain for authentication. Your last response to me made that point loud and clear. Thanks.
>
> And finally, but importantly, what exactly is your use case? How does
> the server expect to benefit from (make access and authorisation
> decisions based on) client certificates?
The case is an organization that was initially using passwords for authentication. That worked properly and was easy to setup. However, in the process of doing that I discovered that all their users had the name of the company as their password. Given that the loss of the information that needs to be protected would be a very significant financial loss to the company, that approach is really not a good idea. I proposed the certificate authentication and management agreed.
-- Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccc
Type: application/octet-stream
Size: 12898 bytes
Desc: not available
URL: <https://urldefense.com/v3/__https://mta.openssl.org/pipermail/openssl-users/attachments/20240409/adbda02f/attachment.obj__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtGH5WTLg$>
------------------------------
Subject: Digest Footer
_______________________________________________
openssl-users mailing list
mailto:openssl-users at openssl.org
https://urldefense.com/v3/__https://mta.openssl.org/mailman/listinfo/openssl-users__;!!FJ-Y8qCqXTj2!Z4_OjCVt2ZxN2QfqMULBlr9PruEFLHmdq-wMr8gkIhKkX19e5-opf4Izyob0knUn_Th1ye1EZNYjAhMs0HPhEkPtt7tKjqY$
------------------------------
End of openssl-users Digest, Vol 113, Issue 6
*********************************************
Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
More information about the openssl-users
mailing list