Q&A with PHK: Integrating H/2 Into Varnish Cache

In part II of our interview with Varnish Cache Chief Architect Poul-Henning Kamp, he discusses what is on the drawing board for Varnish 5.0 as well as his thoughts on HTTP2. (Revisit part one of the interview.)

What benefits will Varnish 5 bring to the community?

We are working on HTTP2 support.

In HTTP1, a connection is a session, and it has one request. There’s only one thing going on at a time. If you have an error, it’s a session error almost by definition. That changes with the multiplexing in HTTP2 and presumably in HTTP3 and whatever will happen in the future.

So right now I’m sorting that out, defining when an error is a request error and when it is session error, and so on, and preparing so that once we slot in HTTP2 all those changes are in place.

We are doing some other cleanups with the storage engine in Varnish as well.

The VCL change between Varnish 3 and 4 was pretty extensive because we split the backend fetch entirely out. I don’t think the 4 to 5 change will be as big. But we’ll need to have something that deals with HTTP2 multiplex session at the multiplex level.

How easy will the upgrade from Varnish 4 to 5 be?

I’m hoping to keep that as a one-hour job as opposed to a three or four-hour job.

Part of the way we are dealing with the devops to developer transition is that we go to a new release schedule. We already know the release date for Varnish 5.0, we have announced it, it will be September 15th this year. Whatever is ready that day will be in Varnish 5. Whatever is not ready won’t be in the release.

So I’m not going to promise what will be in Varnish 5 because if I break a leg, it won’t be there … well, I guess I could program with a broken leg, but… HTTP2 is what we are aiming for now, to get that in as a checkbox item, so people can say they can do it. That’s the current plan, at least.

Are the dynamics of VCL advantageous to the HTTP2 migration?

VCL is the perfect way to deal with the PUSH. I’ve written plenty about the HTTP2 spec. One of the problems with it is that nobody knows how to use PUSH, except for Google who has been playing with it in SPDY. Nobody else has the business logic to do pushes.

The point about PUSH is to hide the SSL negotiation round-trips, but it’s not obvious that pushes are a good idea for that. There may be applications where they are, where you can save two round trips because we know they are going to need this. But in the big scheme of things, it doesn’t look like something that will solve everything and make everything faster. Cutting the round-trips as they do in TLS 1.3 looks like a much better solution.

But VCL will be good for playing with PUSH because it gives you very fine grained information and control. You can play with it in a much more flexible way than in frameworks or JavaScript.

In that sense VCL is the core of Varnish because you can do weird stuff in it. That has a very big potential if PUSH is any good. If PUSH is not any good, we’re just wasting our time.

Other than HTTP2, what trends in web tech should people be preparing for?

We must teach people that they need two Crypto implementations.

Ever since HeartBleed, we haven’t had three weeks without a security advisory against one or another SSL implementation.

If I were running a high-reliability website, I would have one set of proxies running OpenSSL and another set running something else, PolarSSL maybe. Then whenever there is a security advisory against one of them, I can turn off that half of my proxies and keep serving traffic safely.

Is the OpenSSL code currently being worked on?

Oh yeah, everyone jumps on it to see who can publish the next advisory. If you are a security researcher these days, publishing an advisory against an SSL implementation is like the membership card. OpenSSL has had something like a vulnerability per week since HeartBleed, and they have 600,000 lines of code. They’re not done yet.

The constant problems we see in that space will continue for at least a couple of years until this code has been finally cleaned up and sanitized. The only sensible thing one can do is to run multiple Crypto stacks in parallel and turn off the one that doesn’t work this week.

Some of the other SSLs may be better. Amazon wrote a minimal SSL, but it hasn’t really been beaten up yet. But it is good that we're getting alternatives. It used to be that you only had OpenSSL and that was it, that’s not the case anymore. But it is still too early to point to any one SSL library and claim their code is more credible than the others.

I think people are also getting smarter about Crypto because the constant stream of advisories reminds them about it. For instance people are starting to realize how many access points, photocopiers, coffee machines and whatnot where the SSL will never get updated. There’s a lot of embedded stacks where the software just never gets updated. That’s going to change our attitude to software quality.

Related to SSL, we have the PROXY protocol in Varnish, do you see that being extended both toward the client side and the backend side in Varnish 5 or 6?

On the backend side, the goal is for backends to be anything: database-based, file-based, network-based. Whatever you want to do. That means writing a Varnish backend that uses a encrypted protocol to talk to something somewhere is now something you can do in a VMOD, which means I don’t have to write the code.

Being able to run encrypted to the backend makes sense. If you are running your Varnish in a data center somewhere, and you have the server back home, you want to be able to encrypt that stream. Whether that will be part of Varnish core or whether we’ll have such a VMOD as part of the Varnish distribution, I don’t know. I don’t think anyone has published such a VMOD yet and until someone does, it’s a theoretical question. But it should be possible now, we just need somebody to write the code.

Client side, is there anything else we can expect in Varnish 5?

As soon as you say we are going to link up against this SSL implementation, you’re stuck whenever you have an advisory against that. So my decision not to link against OpenSSL is even more firm than it ever was. TLS 1.3 may change that. TLS 1.3 is a very interesting fresh look at how to do encryption and much more targeted to the HTTP needs. Time will tell when that will be ready for use.

It should be possible to make a much smaller and much more sane implementation of TLS 1.3 because they’ve gone, “We don’t need all these options; we don’t need all these different choices of Crypto. Just cut it down to one small thing to manage.” So when that is ready, the crypto question will have to be revisited. But until then, we’ll interface with Crypto on the client side for the PROXY Protocol. And you get to pick your poison and put whatever you trust in front of it –Hitch, HAPROXY, some expensive hardware solution – whatever you like.

Read more about the ins and outs of Varnish Cache. Read the Varnish Book.