Mailing List Archive

That is an interesting exercise, thank you, Dridi.

For TLS on TCP, I would hope that passing the session key and file descriptor
would work. Have you checked already to which extend this is supported by
existing library code?

Yet with the H3/QUIC madness on the horizon, I am not sure if connect()ing the
SOCK_DGRAM and passing the fd would work. The way I read the QUIC draft,
connections are primarily identified by their ID and migrations need to be
supported. I have made no coding attempt on my own, but my impression was that
the natural implementation the authors had in mind was a recvfrom(2) loop
matching packets based on their connection ID with spoof detection.

So, Dridi, have you had a closer look yet if/how your idea could work with QUIC?

Somehow related: How about having the process owning the private keys also
handle all receives into multiple ringbuffers, somehow similar to vsm, but with
overrun protection?

Nils

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

--------
In message <bfad471b-d009-57b4-e621-adefde9747d2@schokola.de>, Nils Goroll writ
es:

>Yet with the H3/QUIC madness on the horizon,

No, they actually dealt with this in the design, so that "keyless"
operation is more or less the natural architecture for QUIC.

If we want to do TCP/TLS, we should also aim firmly for the "keyless" model.

I'm hoping we can to raid the hitch source code to build the "keymaster" process.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Hi Nils,

On Wed, Sep 4, 2019 at 7:57 AM Nils Goroll <slink@schokola.de> wrote:
>
> That is an interesting exercise, thank you, Dridi.

Thanks for reading.

> For TLS on TCP, I would hope that passing the session key and file descriptor
> would work. Have you checked already to which extend this is supported by
> existing library code?

I haven't, I really only had a short window to think about this and
give it a try, and I burned a large amount of that spare time to play
with asciinema...

> Yet with the H3/QUIC madness on the horizon, I am not sure if connect()ing the
> SOCK_DGRAM and passing the fd would work. The way I read the QUIC draft,
> connections are primarily identified by their ID and migrations need to be
> supported. I have made no coding attempt on my own, but my impression was that
> the natural implementation the authors had in mind was a recvfrom(2) loop
> matching packets based on their connection ID with spoof detection.
>
> So, Dridi, have you had a closer look yet if/how your idea could work with QUIC?

Not at all. The proposed model falls short as soon as you have any
kind of key renegotiation, except that being a UDS you could in theory
pass the fd back and forth whenever you need private key privileges. I
really really don't like the idea of a two-way channel though.

> Somehow related: How about having the process owning the private keys also
> handle all receives into multiple ringbuffers, somehow similar to vsm, but with
> overrun protection?

No opinion, I haven't thought about this. I'm literally back today and
will be away again for the rest of the week.

I will reply in greater details to Poul-Henning's response.

Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> In message <bfad471b-d009-57b4-e621-adefde9747d2@schokola.de>, Nils Goroll writ
> es:
>
> >Yet with the H3/QUIC madness on the horizon,
>
> No, they actually dealt with this in the design, so that "keyless"
> operation is more or less the natural architecture for QUIC.
>
> If we want to do TCP/TLS, we should also aim firmly for the "keyless" model.
>
> I'm hoping we can to raid the hitch source code to build the "keymaster" process.

I have given more thought to this and I'm torn between "this is 2019
and we still don't support HTTPS" and the very good reasons why we
don't. However I still think we should support it and I gave a tiny
bit more thoughts to this.

First, in-kernel TLS is coming, and while it will likely take forever
to become ubiquitous *cough* enterprise linux *cough* in the long run
it will probably be our best option: we keep our usual read and
write[v] calls and nothing changes for us.

Until then though, we might want to add support for "session
operations" to replace the read/write[v] calls with
SSL_read/SSL_write[v] for example. Ideally that would be with a
vmod-openssl that later could compete with a vmod-ktls or
vmod-other_tls_library, possibly written by third parties *cough*
uplex? *cough* since we can't reasonably support them all ;-)

With customizable session operations, we can now also replace other
calls like accept or connect. That might be our cue to add session
subroutines in VCL.

But once we have that we circle back to handshakes. And I very much
agree that a keyless approach would be best. However this is still
2019 so I think we should own it, and not rely on a third party. We
should provide a comprehensive solution, for either HTTPS or http/3,
and therefore we should provide a minimalist keyserver implementation.
Whether it is a new varnishkeyserver program, or a new varnishd -k
flag with a 3rd long-lived varnishd process, possibly working with a
socketpair like my MXC thought experiment, I think we should provide
that.

Have a nice VDD!

Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Is Varnish finally going to start supporting https so we no longer have to
offload/completely replace it with nginx?

On Mon, Sep 23, 2019, 11:16 Dridi Boukelmoune <dridi@varni.sh> wrote:

> On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
> >
> > --------
> > In message <bfad471b-d009-57b4-e621-adefde9747d2@schokola.de>, Nils
> Goroll writ
> > es:
> >
> > >Yet with the H3/QUIC madness on the horizon,
> >
> > No, they actually dealt with this in the design, so that "keyless"
> > operation is more or less the natural architecture for QUIC.
> >
> > If we want to do TCP/TLS, we should also aim firmly for the "keyless"
> model.
> >
> > I'm hoping we can to raid the hitch source code to build the "keymaster"
> process.
>
> I have given more thought to this and I'm torn between "this is 2019
> and we still don't support HTTPS" and the very good reasons why we
> don't. However I still think we should support it and I gave a tiny
> bit more thoughts to this.
>
> First, in-kernel TLS is coming, and while it will likely take forever
> to become ubiquitous *cough* enterprise linux *cough* in the long run
> it will probably be our best option: we keep our usual read and
> write[v] calls and nothing changes for us.
>
> Until then though, we might want to add support for "session
> operations" to replace the read/write[v] calls with
> SSL_read/SSL_write[v] for example. Ideally that would be with a
> vmod-openssl that later could compete with a vmod-ktls or
> vmod-other_tls_library, possibly written by third parties *cough*
> uplex? *cough* since we can't reasonably support them all ;-)
>
> With customizable session operations, we can now also replace other
> calls like accept or connect. That might be our cue to add session
> subroutines in VCL.
>
> But once we have that we circle back to handshakes. And I very much
> agree that a keyless approach would be best. However this is still
> 2019 so I think we should own it, and not rely on a third party. We
> should provide a comprehensive solution, for either HTTPS or http/3,
> and therefore we should provide a minimalist keyserver implementation.
> Whether it is a new varnishkeyserver program, or a new varnishd -k
> flag with a 3rd long-lived varnishd process, possibly working with a
> socketpair like my MXC thought experiment, I think we should provide
> that.
>
> Have a nice VDD!
>
> Dridi
> _______________________________________________
> varnish-dev mailing list
> varnish-dev@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>

--------
In message <CABoVN9D0LGaRNorsPogRCkKKojpXJ9vDLWHi=tAPGa-tzYz1_Q@mail.gmail.com>
, Dridi Boukelmoune writes:

>I have given more thought to this and I'm torn between "this is 2019
>and we still don't support HTTPS" and the very good reasons why we
>don't. However I still think we should support it and I gave a tiny
>bit more thoughts to this.

Absolutely, all such decisions needs to be revisited as circumstances
change.

>First, in-kernel TLS is coming,

Yes, and about f**king I might add...

(See also: https://people.freebsd.org/~gallatin/talks/euro2019.pdf)

Unfortunately, the kernel people only seem to want to do the easy
part :-(

https://reviews.freebsd.org/D21277

>But once we have that we circle back to handshakes. And I very much
>agree that a keyless approach would be best. However this is still
>2019 so I think we should own it, and not rely on a third party.

I'm not in any hurry to add crypto code to our plate in any way
shape and form.

The primary reason is that as far as I know there are *at best* 1½
persons in the project with skills which *approximate* what would
be required.

The secondary reason is that neither of them are particularly eager
to add another job to their workload.

I can *possibly* be persuaded that we can handle session keys, and
I will be perfectly happy to point at a 3rd party keyserver packages
and say "that's where you get your keys from".

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev