为什么没有安全套接字层？

这有点像是一个常见问题，但答案太大了，不适合我们用来回答这些问题的边距。

目前还没有在Varnish中增加对SSL的支持的计划，原因有很多。

首先，我还没有看到一个源代码不是噩梦的SSL库。

在我撰写本文时，Varnish源代码树包含82.595行.c和.h文件，包括JEMalloc(12.236行)和Zlib(12.344行)。

导入到FreeBSD中的openssl有340.722行代码，比Varnish源代码大9倍，比Zlib或JEMalloc各自大27倍。

这应该会让您了解到SSL的规范实现有多么复杂。

其次，它并不是世界上最好的源代码。即使我不知道它是做什么的，但它的很多方面都让我害怕。

以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 ... */

我希望他们知道自己在做什么，但这一评论并没有完全抓住这一点，不是吗？

但让我们假设可以找到一个好的SSL库，Varnish会对它做什么？

我们会终止SSL会话，这样做会消耗大量的CPU周期。我们不能简单地告诉内核把字节放在套接字上，而是要把数据从SSL库中取出，然后写到套接字中。

在性能方面，这与在单独的进程中运行SSL代理有显著不同吗？

不，它不会，因为Varnish必须做的方式是...启动一个单独的进程来执行SSL处理。

除了在子进程中隔离处理它们的代码之外，我们没有其他方法可以保证秘密的CRYPTO位不会泄漏到它们不应该泄漏的任何地方，因此大量的Varnish永远不会接近证书，即使在核心转储期间也是如此。

我能编写一个比已有的更好的独立的SSL代理进程吗？

可能不会，除非我还编写了自己的SSL实现库，包括对硬件加密引擎的支持。

这不是我小时候梦想做的事情之一，如果我现在梦见它，我会称之为噩梦。

因此，在我看来，资产负债表列出了积极的一面，而其他一切都堆积在消极的一面，这使得甚至考虑它都是巨大的时间和精力的浪费。

保尔-亨宁，2011-02-15