On Fri, 1 May 2026 08:52:44 +0200
Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:

> 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.
> 

Agreed.

(And since that check is done in tls_get_peer_cert_info(), which
is not exported, there's no obvious place to document it ... so Jan's
suggestion makes good sense)