>> 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@xxxxxxxxxxx> On Behalf Of openssl-users-request@xxxxxxxxxxx Sent: Wednesday, April 10, 2024 1:36 AM To: openssl-users@xxxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxxx You can reach the person managing the list at mailto:openssl-users-owner@xxxxxxxxxxx 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@xxxxxxxxxxx> To: mailto:openssl-project@xxxxxxxxxxx, OpenSSL User Support ML <mailto:openssl-users@xxxxxxxxxxx>, OpenSSL Announce ML <mailto:openssl-announce@xxxxxxxxxxx> Subject: OpenSSL version 3.3.0 published Message-ID: <mailto:ZhU64O8mTQOAQpyT@xxxxxxxxxxx> 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@xxxxxxxx> To: mailto:openssl-users@xxxxxxxxxxx Subject: SSL_accept errors Message-ID: <mailto:A0FFBB91-3F64-433E-86C0-4643F1150F4B@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx> To: Michael Wojcik via openssl-users <mailto:openssl-users@xxxxxxxxxxx> Subject: Questions Message-ID: <mailto:A2803C77-2B9A-43E0-BA0A-721BC89A0499@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> To: mailto:openssl-users@xxxxxxxxxxx Subject: Re: Questions / SSL_accept errors (soliciting client certificates) Message-ID: <mailto:ZhWB7Sq3CStLtoev@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx> To: mailto:openssl-users@xxxxxxxxxxx Subject: Re: Questions / SSL_accept errors (soliciting client certificates) Message-ID: <mailto:89DCA32D-14BA-4734-9DCD-D03E4A8FB7F2@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxx 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.
