Index | Thread | Search

From:
Jan Klemkow <jan@openbsd.org>
Subject:
Re: [diff] httpd: pass through dn from tls client cert to fcgi
To:
Jack Burton <jack@saosce.com.au>
Cc:
Claudio Jeker <cjeker@diehard.n-r-g.com>, tech@openbsd.org
Date:
Tue, 5 May 2026 17:22:57 +0200

Download raw body.

Thread
On Fri, May 01, 2026 at 04:43:56PM +0930, Jack Burton wrote:
> 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)

Claudio is right tls_conninfo_populate() in libtls guaranties that
tls_peer_cert_provided() will fail, if subject is NULL.  I missed that
in my first review.  So, your original diff is ok for me though.

ok jan@