TLS sandboxing

Dridi Boukelmoune dridi at varni.sh
Mon Sep 23 08:14:28 UTC 2019


On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> In message <bfad471b-d009-57b4-e621-adefde9747d2 at 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


More information about the varnish-dev mailing list