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 <dr...@varni.sh> wrote: > On Wed, Sep 4, 2019 at 8:02 AM Poul-Henning Kamp <p...@phk.freebsd.dk> > wrote: > > > > -------- > > In message <bfad471b-d009-57b4-e621-adefde974...@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 >
_______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
