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