> On Apr 9, 2024, at 22:02, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > > On Tue, Apr 09, 2024 at 05:35:53PM -0700, Doug Hardie wrote: > >> Attached is the result for the first connection: > > There are a few reasons turned out a bit less than informative. > > - You give no indication of whether this is a successful handshake > or a failure. It just completes abruptly without even an error > indication (encrypted alert) from either side. > > - The handshake used TLS 1.3, which encrypts all the interesting > parts of the handshake. To really see what's going on, you might > to artificially limit the server's supported TLS protocols to TLS 1.2 > > - My "tshark" instructions strip away which side is sending a given > message, making it somewhat unclear, but the presented decode > was largely clear turn-taking. > > To debug TLS 1.3, you probably want to enable handshake and error logging (info) > callbacks on the server, and not abbreviate the reported errors to such > a degree that all context is lost. It should be clear (to a trained > eye) from a reported SSL alert error, for example whether the alert was > a client to server or a server to client alert. This means not > summarising the error messages, but reporting them in full. Finally got time to get back to this. Here are the server logged errors for the first 6 connections. They are all basically identical. The first message is the SSL error and the second is the one returned by SSL_accept. I do not have access to any client logs or error indications. Both of these errors were recorded immediately after the SSL_accept call. Apr 18 16:15:17 <3.7> RIB wncert[20518]: SSL Error: Accept failed - 0020A163511D0000:error:0A000416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1586:SSL alert number 46 Apr 18 16:15:17 <3.7> RIB wncert[20518]: logerr msg=Accept failed msg2=No error: 0 These 6 connection attempts occurred prior to the user selecting the proper certificate to use. Once that was done, there was only on additional connection and it was successful. No error returns and the server returned the proper response. > >>> 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. > > I may look into it. > >>> 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. > > Post the relevant log entries verbatim, unsummarised. > >>> ... >>> 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. > > It may avoid some of the problems. That was done before the tests above. I don't see any significant changes other than there are no more error messages indicating sessions. > >>> 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. > > But what list of CAs is sent in the certificate request? If it is the > CA names from full default system trust store, that could be unhelpful, > as well as a security issue, since any of those CAs could impersonate > your clients. For client authentication, Postfix only trusts client > certificate or public key fingerprints, bypassing the CA trust quagmire, > that is typically unhelpful (and a major security risk) for client certs. Not sure how to answer this. I have set SSL_CTX_load_verify_dir (ssl_ctx, "/dev/null"). There is only my root certificate used to generate the client certificates in SSL_CTX_load_verify_locations and SSL_load_client_CA_file. My server cert (from letsencrypt) is set in SSL_CTX_use_certificate_file along with it's key in SSL_CTX_use_PrivateKey_file. > > >>> 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. > > If this is for browser-based applications, you're probably fighting a > losing battle. Client certificates just haven't worked at all well for > interactive use by most users. They're fine for datacentre > machine-machine comms, and in some specialised orgs (like US DoD?) where > users have no choice, and presumably get adequate support to make it > work. > > Find a way to prevent password sharing, to check password quality, and > DO NOT force periodic password rotation, which ensures users choose bad > passwords. Then consider various second factor options, TOTP and HOTP > perhaps, or SMS, ... Some single-systems also include risk metrics, > to bypass second factors when things look "normal". This is a high intensity, time critical, environment. Management doesn't want time wasted trying find/remember passwords. -- Doug
