On Fri, May 01, 2026 at 03:05:28PM +0930, Jack Burton wrote:
> On Thu, 30 Apr 2026 20:07:58 +0200
> Jan Klemkow <j.klemkow@wemelug.de> wrote:
> > On Thu, Apr 30, 2026 at 03:26:20PM +0930, Jack Burton wrote:
> > > On Wed, 29 Apr 2026 21:49:29 +0200
> > > Jan Klemkow <jan@openbsd.org> wrote:  
> > > > I also like this feature and also thought about it in the past.
> > > > 
> > > > But, I guess a certificate where the subject is NULL, may crash
> > > > the httpd?  
> > > 
> > > Interesting.  Well caught.  I hadn't thought of that, as it makes no
> > > sense at all to have a *client* certificate without a subject field.
> > > Nevertheless, RFC 5280 does not prohibit it, so I guess it's
> > > possible and therefore it makes sense to check for it.  
> > 
> > In this scenario it does not matter, if its legal or not to have a
> > subject-less client certificate.  The important question is: Can an
> > attacker craft a certificate which leads to NULL in ->subject, which
> > he can use to DoS the httpd?
> 
> Yes, too true (although I'd suggest that both matter: a deliberate,
> malicious DoS and a DoS caused by user error each have the same end
> result).
> 
> The most recent 3 versions of the diff I posted all address your concern
> (NULL subject no longer causes a crash, nor any error; instead it just
> gets ignored).  Are any of those suitable?
 
Just to be clear, libtls does not allow a NULL subject on a session that
has a client cert. So the check for tls_peer_cert_provided() already
ensures that tls_peer_cert_subject() will not return NULL.
I have no idea if e.g. libretls is doing the same. The only way to know is
by inspecting the code so I think you can not really depend on it.

-- 
:wq Claudio