Questions / SSL_accept errors (soliciting client certificates)

[Doug Hardie]

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 at dukhovni.org> 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.