Default page

Your IP: 216.73.216.96
Server IP: 147.93.97.220
Server: Linux srv843233 6.8.0-71-generic #71-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 22 16:52:38 UTC 2025 x86_64
Server Software: nginx/1.28.0
PHP Version: 8.2.29
Buat File | Buat Folder
Dir : ~/usr/share/doc/varnish/html/_sources/phk/
View File Name : ssl.rst.txt

..
	Copyright (c) 2011-2014 Varnish Software AS
	SPDX-License-Identifier: BSD-2-Clause
	See LICENSE file for full text of license

.. _phk_ssl:

============
Why no SSL ?
============

This is turning into a bit of a FAQ, but the answer is too big to fit
in the margin we use for those.

There are a number of reasons why there are no plans in sight that will
grow SSL support in Varnish.

First, I have yet to see a SSL library where the source code is not
a nightmare.

As I am writing this, the varnish source-code tree contains 82.595
lines of .c and .h files, including JEmalloc (12.236 lines) and
Zlib (12.344 lines).

OpenSSL, as imported into FreeBSD, is 340.722 lines of code, nine
times larger than the Varnish source code, 27 times larger than
each of Zlib or JEmalloc.

This should give you some indication of how insanely complex
the canonical implementation of SSL is.

Second, it is not exactly the best source-code in the world.  Even
if I have no idea what it does, there are many aspect of it that
scares me.

Take this example in a comment, randomly found in s3-srvr.c::

	/* Throw away what we have done so far in the current handshake,
	 * which will now be aborted. (A full SSL_clear would be too much.)
	 * I hope that tmp.dh is the only thing that may need to be cleared
	 * when a handshake is not completed ... */

I hope they know what they are doing, but this comment doesn't exactly
carry that point home, does it ?

But let us assume that a good SSL library can be found, what would
Varnish do with it ?

We would terminate SSL sessions, and we would burn CPU cycles doing
that.  You can kiss the highly optimized delivery path in Varnish
goodbye for SSL, we cannot simply tell the kernel to put the bytes
on the socket, rather, we have to corkscrew the data through
the SSL library and then write it to the socket.

Will that be significantly different, performance wise, from running
a SSL proxy in separate process ?

No, it will not, because the way varnish would have to do it would
be to ... start a separate process to do the SSL handling.

There is no other way we can guarantee that secret krypto-bits do
not leak anywhere they should not, than by fencing in the code that
deals with them in a child process, so the bulk of varnish never
gets anywhere near the certificates, not even during a core-dump.

Would I be able to write a better stand-alone SSL proxy process
than the many which already exists ?

Probably not, unless I also write my own SSL implementation library,
including support for hardware crypto engines and the works.

That is not one of the things I dreamt about doing as a kid and
if I dream about it now I call it a nightmare.

So the balance sheet, as far as I can see it, lists "It would be
a bit easier to configure" on the plus side, and everything else
piles up on the minus side, making it a huge waste of time
and effort to even think about it..

Poul-Henning, 2011-02-15