On Sat, 26 May 2018 22:44:56 +0930
Jack Burton wrote:
> This diff adds three new TLS_PEER_* fastcgi variables: ISSUER, SERIAL
> & SUBJECT.
>
> That seems the logical next step in making tls client certs usable for
> authorisation & accounting. Last week's commit (
This diff adds three new TLS_PEER_* fastcgi variables: ISSUER, SERIAL &
SUBJECT.
That seems the logical next step in making tls client certs usable for
authorisation & accounting. Last week's commit (thanks Joel!) took care
of authentication.
The cert subject on its own should suffice for the sim
Just noticed this in passing while working on something else.
Index: lib/libtls/man/tls_conn_version.3
===
RCS file: /cvs/src/lib/libtls/man/tls_conn_version.3,v
retrieving revision 1.7
diff -u -p -r1.7 tls_conn_version.3
--- lib/libt
My attempts to get this accepted last year stalled.
As best I recall, the main stumbling block was agreeing on how much /
exactly which client cert data to pass through to fastcgi (my view was
that passing the whole client cert chain would be ideal).
So, here's a stripped down version that passes
Adds a regression test for the tls client authentication diff from my
last post.
Index: tests/Client.pm
===
RCS file: /cvs/src/regress/usr.sbin/httpd/tests/Client.pm,v
retrieving revision 1.1
diff -u -p -r1.1 Client.pm
--- tests/Clien
On Tue, 8 Aug 2017 15:10:36 +0930
Jack Burton wrote:
> On Tue, 08 Aug 2017 14:23:02 +1000
> Joel Sing wrote:
> > On Saturday 29 July 2017 20:49:18 Jan Klemkow wrote:
> > > In the End, I found and fixed the real bug here:
> > >
> > > @@ -430,7 +438,11 @@ c
On Tue, 08 Aug 2017 14:23:02 +1000
Joel Sing wrote:
> On Saturday 29 July 2017 20:49:18 Jan Klemkow wrote:
> > Hi Jack,
> >
> > On Fri, Jul 28, 2017 at 02:05:34AM +0930, Jack Burton wrote:
> > > On Thu, 27 Jul 2017 13:10:14 +0200
> > >
> > >
On Sat, 29 Jul 2017 20:49:18 +0200
Jan Klemkow wrote:
> On Fri, Jul 28, 2017 at 02:05:34AM +0930, Jack Burton wrote:
> > On Thu, 27 Jul 2017 13:10:14 +0200
> >
> > > But, I found a bug in the part of the FastCGI variables. The
> > > following condition is alw
On Thu, 27 Jul 2017 13:10:14 +0200
Jan Klemkow wrote:
> Hi Jack,
>
> On Fri, Jul 21, 2017 at 06:33:43PM +0930, Jack Burton wrote:
> > Thoughts?
>
> I've tested your diff. The main feature looks fine to me. TLS
> connections with and with out Clients certs,
Here's another iteration of my diff, updated to work with the new &
improved imsg transfers for tls config that jsing@ committed yesterday.
That helped simplify this diff significantly.
Other changes since the last version:
* uses simpler config (one new directive instead of three);
* drops the t
Now that libtls supports CRL checking (thanks jsing@ & beck@ for your
help to get that in), let's have another go at adding tls client
verification to httpd.
This diff does just that, with options to verify tls client certs,
optionally with full chain CRL checks.
All the same info is passed throu
Just noticed this in passing & thought I'd mention it.
Index: starttls.8
===
RCS file: /cvs/src/share/man/man8/starttls.8,v
retrieving revision 1.22
diff -u -p -r1.22 starttls.8
--- starttls.8 24 Dec 2015 16:54:37 - 1.22
+++
X509_VERIFY_PARAM_set_flags(3) states that
X509_VERIFY_PARAM_set_flags() and X509_VERIFY_PARAM_clear_flags() both
"return 1 for success or 0 for failure".
But both those functions always return 1 (unless param is null, in
which case they don't return at all but segfault instead -- but none of
the
On Thu, 30 Mar 2017 22:17:46 +1030
Jack Burton wrote:
> One of our sites has a need to require/verify TLS client certs,
> without the overhead & complexity of apache / nginx, etc.
>
> OpenBSD's httpd seemed the obvious candidate, and I figured that the
> feature would
On Sun, 2 Apr 2017 06:27:45 +0930
Jack Burton wrote:
> On Sat, 01 Apr 2017 18:22:17 +
> Bob Beck wrote:
> > There will be some libtls api additions post 6.1 to get the peer
> > cert in PEM format
>
> Thanks Bob. That sounds like exactly what's needed
On Sat, 01 Apr 2017 18:22:17 +
Bob Beck wrote:
> There will be some libtls api additions post 6.1 to get the peer cert
> in PEM format
Thanks Bob. That sounds like exactly what's needed. Happy to wait.
> In the meantime, testing snaps prior to 6.1 should be the priority.
> not a talkathon.
On Fri, 31 Mar 2017 22:21:38 +0200
Joerg Sonnenberger wrote:
> On Fri, Mar 31, 2017 at 01:03:44PM -0700, William Ahern wrote:
> > Basically, anything short of passing through the entire certificate
> > is going to be severely limiting and frustrating, to the point of
> > uselessness.
>
> Passin
On Fri, 31 Mar 2017 13:03:44 -0700
William Ahern wrote:
> On Thu, Mar 30, 2017 at 10:31:06PM +1030, Jack Burton wrote:
>
> > Personally, I'm leaning towards either local CRL file checking in
> > httpd (with minimal changes to libtls), or passing through enough
> >
On Thu, 30 Mar 2017 21:47:34 +0200
Jan Klemkow wrote:
> I'm not a developer (just a contributor), but I worked on httpd client
> certs a year ago, too. (https://marc.info/?t=14528592613&r=1&w=2)
Interesting. Thanks Jan, I hadn't seen your earlier diffs before (my
fault -- I guess I should ha
Earlier this evening I proposed a patch that adds support for
requiring/verifying TLS client certificates to httpd. See my last post.
But that only solves half the problem (checking that the client cert
was issued by a locally-trusted CA and has not yet expired).
The other (and in my opinion equa
One of our sites has a need to require/verify TLS client certs,
without the overhead & complexity of apache / nginx, etc.
OpenBSD's httpd seemed the obvious candidate, and I figured that the
feature would be useful to others too -- see attached diff for an
initial implementation.
Of course, there
On Wed, 2015-07-15 at 23:38 +0930, Jack Burton wrote:
> Sorry, I don't have any hosts running -current at the moment, but I've
> written a trivial patch against 5.7-stable to treat that particular
> failure mode in the same way as was already being done for EV_TIMEOUTs.
> Th
In 5.7-stable & -current, httpd, when listening for TLS, does not close
the client socket when tls_accept_socket() returns any non-recoverable
error. The problem manifests most often when a client connects but does
not attempt TLS handshake.
Steps to reproduce:
* Configure httpd to listen for TLS
23 matches
Mail list logo
