Really off the wall idea - is it possible that the client is trying to establish a QUIC session? -- Doug > 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. > >>> 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 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. > > >>> 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". > > -- > Viktor.
