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