Questions / SSL_accept errors (soliciting client certificates)

[Viktor Dukhovni]

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.