TLS sandboxing

[Andrei]

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 at varni.sh> wrote:

> 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
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20190924/715d6b91/attachment.html>