varnish with ssl

Poul-Henning Kamp phk at
Wed Apr 7 23:30:49 CEST 2010

In message <h2sd002c4031004071420g8d5bca97nac3335d059d61631 at>, Mi
chael Fischer writes:
>On Wed, Apr 7, 2010 at 2:07 PM, Poul-Henning Kamp <phk at> wrot=

>RAM is cheap.  Besides, as a shared library the cost is amortized
>among all processes using it.

You're missing my point by a wide margin here.

>>  But that all sounds like "second systems syndrome" thinking to me,
>>  it does not really sound lige a genuine "The world would become
>>  a better place" feature request.
>Well, there are a couple of benefits:
>(1) stunnel doesn't scale particularly well, and can't scale across
>multiple CPUs in any event;

There are other SSL proxies than stunnel.

>(2) As someone else pointed out, Varnish can only do effective logging
>of and access control pertaining to the peer IP if the SSL negotiation
>is done in-process.  stunnel won't spoof the peer IP for Varnish (and
>arguably no secure kernel should allow it to).

We're working on that bit, as long as your SSL proxy sends a trustworthy
header with the client IP, you will be able to test on it.

>> 2. I have looked at the OpenSSL source code, I think it is a catastrophe
>> =A0 waiting to happen. =A0In fact, the only thing that prevents attackers
>> =A0 from exploiting problems more actively, is that the source code is
>> =A0 fundamentally unreadable and impenetrable.
>Is GNU TLS any better? I've not used it.

Not significantly, and furthermore, we try very hard to stay clear
of GPL code, in order to not encumber Varnish with a multiple incompatible


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-misc mailing list