My $0.02 agrees with you. I'd also add that by definition, SSL represents data that is secure between the server and the user. Caching that data (or having it even pass through a cache) is conceptually incompatible.
Obviously, SSL pages often contain static content (images), which would be nice to serve from a cache. But there are already easily-applied and scalable SSL solutions to Varnish installations: Varnish's lack of SSL support is essentially irrelevant and entirely /consistent/. Additionally, if you have various backend webservers (say, Apache plus nginx plus varnish) it's nice to have one common SSL layer to configure and maintain, especially if some of those backends also lack built-in SSL. Commercial load balancers typically have SSL support and work as that common SSL layer, and Pound is one OSS example. Varnish is a great caching reverse proxy. If I want SSL+PHP+LDAP+cache+proxy in one executable (and I don't) there's an app for that. -- kb On Apr 7, 2010, at 2:30 PM, Poul-Henning Kamp wrote: > In message <[email protected]>, > Mi > chael Fischer writes: >> On Wed, Apr 7, 2010 at 2:07 PM, Poul-Henning Kamp <[email protected]> wrot= >> e: > >> 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 > licenses. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [email protected] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > varnish-misc mailing list > [email protected] > http://lists.varnish-cache.org/mailman/listinfo/varnish-misc _______________________________________________ varnish-misc mailing list [email protected] http://lists.varnish-cache.org/mailman/listinfo/varnish-misc
