Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
V
varnish-cache
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Commits
Open sidebar
varnishcache
varnish-cache
Commits
2fface76
Commit
2fface76
authored
Feb 15, 2011
by
Poul-Henning Kamp
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
A short rant about why I will not add SSL support to Varnish.
parent
1a8f1056
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
76 additions
and
0 deletions
+76
-0
index.rst
doc/sphinx/phk/index.rst
+1
-0
ssl.rst
doc/sphinx/phk/ssl.rst
+75
-0
No files found.
doc/sphinx/phk/index.rst
View file @
2fface76
...
...
@@ -8,6 +8,7 @@ You may or may not want to know what Poul-Henning think.
.. toctree::
ssl.rst
gzip.rst
vcl_expr.rst
ipv6suckage.rst
...
...
doc/sphinx/phk/ssl.rst
0 → 100644
View file @
2fface76
.. _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
goodby 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
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment