TLS sandboxing

Poul-Henning Kamp phk at
Mon Sep 23 22:02:27 UTC 2019

In message <CABoVN9D0LGaRNorsPogRCkKKojpXJ9vDLWHi=tAPGa-tzYz1_Q at>
, Dridi Boukelmoune writes:

>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.

Absolutely, all such decisions needs to be revisited as circumstances

>First, in-kernel TLS is coming,

Yes, and about f**king I might add...

(See also:

Unfortunately, the kernel people only seem to want to do the easy
part :-(

>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.

I'm not in any hurry to add crypto code to our plate in any way
shape and form.

The primary reason is that as far as I know there are *at best* 1½
persons in the project with skills which *approximate* what would
be required.

The secondary reason is that neither of them are particularly eager
to add another job to their workload.

I can *possibly* be persuaded that we can handle session keys, and
I will be perfectly happy to point at a 3rd party keyserver packages
and say "that's where you get your keys from".

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the varnish-dev mailing list