Using Varnish with SaaS HTTPS backend servers?

Question

I want to configure Varnish to use HTTPS(!) services as backend services. The key here is the SSL part of the connection to the backend service! I have limited control over those HTTPS backend services (think of them as SaaS services hosted in the cloud).

It's a setup like this: User-Agent -> AWS ELB as SSL terminator -> Varnish in AWS -> HTTPS SaaS services in the cloud

The reasons for that are as follows: - I want to use Varnish ESI to decorate the SaaS service UI with my own custom page header & footer. - By having all requests going through Varnish, I get additional analytics data about the SaaS service which I wouldn't get otherwise - I can use Varnish to re-write URLs of the SaaS service effectively hiding the SaaS service URL from the end-users

I am able to use AWS ELB as SSL terminator towards the user-agent, but how do I get Varnish to access the HTTPS SaaS service as an origin server?

Background: I work on a web portal where we will present a number of different services (all services have their own existing UI, i.e. they don't have headless RESP APIs!) to our customers. The main thing that pulls all those services together is a common page header and footer (page header shows top level navigation and login/username logout).

The types of services we have are as follows, all have their own UI layer which we don't want to replicate: - White-labeled 3rd party SaaS service (think of e.g. Zendesk or Salesforce), hosted in the cloud - In-house developed JavaEE/Spring services which are hosted in AWS - Services that other teams in our company developed, but they are hosted in our own data center

Adding ESI includes is fine for each of those services, but I don't want to have to duplicate work of re-implementing the page header/footer multiple times for each service.

Sextillion

I just saw this article: komelin.com/articles/https-varnish – Thant

Answer 1

I ran into a similar requirement recently where the desired back-end needed to be accessed using https.

There are, of course, a lot of objections that could be raised as to why this is the wrong way to do it... but in this case, I was constrained by the fact that I needed the data encrypted to the back-end, a significant geographical distance, and the fact that a VPN was not possible because of the ownership and control of the various systems.

Here is a workaround that from my limited testing seems to have potential to solve this problem using stunnel4.

Sample lines from the configuration:

client  = yes
[mysslconnect]
accept  = 8888
connect = dest.in.ation.host.or.ip:443

Now, stunnel4 is listening to port 8888 on my local (varnish) machine, and each time an incoming connection arrives, it sets up an ssl connection to port 443 on the remote system.

A connection to 127.0.0.1 port 8888 on the local server allows me to speak cleartext HTTP to the destination back-end server, and this occurs over an SSL connection that is actually managed by stunnel4... so configuring varnish to use 127.0.0.1:8888 as the back-end does what I intend because varnish thinks it's speaking to an ordinary http server, unaware of what stunnel4 is doing on its behalf.

I can't vouch for the scalability or reliability of this, since I've only just not gotten it working, but so far it does seem to be a viable workaround to this limitation in varnish.

Irreligious

Any update on the reliability or scalability of this approach? – Becoming

@Becoming the stunnel4 aspect of this setup has been working flawlessly since I set it up... although shortly after I posted this, I switched the load balancer itself from varnish to haproxy -- which has exactly the same limitations on back-end SSL in version 1.4 as varnish has, so I'm still using stunnel4 in the same way. I didn't have any problems with varnish or any compelling reason to switch to haproxy -- I was actually evaluating both at the time, and this application didn't need caching, so I went with the option that felt the most lightweight. – Irreligious

Awesome, thanks for the update, appreciate it. I'm hitting some SNI issues, but I'll figure those out... :-) – Becoming

Answer 2

Accessing HTTPS backends in Varnish isn't supported. Varnish speaks HTTP to the backends.

If you want to access HTTPS backend content you'll have to proxy it through another daemon/proxy that adds/strips HTTPS. There are quite a few choices for this, one of which is stunnel which is tried and tested.

From what you are describing (rewriting content) I'd say that you are pretty close to using the wrong hammer. Varnish might not be the best tool for this, have you considered gluing things together with mod_rewrite/mod_substitude instead?

Prologize

Removing the TLS with SSL Terminator and then readding it with stunnel?? Correct me if I'm wrong but it seems unlogical to me, or should I say overkill? I mean you want to use cache to make your app faster but use lots of additional CPU cycles because of SSL Terminator and stunnel and other resources to make it work. This adds an extra network latency too, I wonder how much performance gain would be made with these configuration(SSL Terminator & stunnel).. – Ursala

Starting with version 4.0 Varnish Cache Plus (the commercial version) supports HTTPS backend. varnish-software.com/plus/ssl-tls-support – Zambia

Answer 3

This is supported by Varnish Cache Plus which isn't free.

backend default {
    .host = "backend.example.com";
    .port = "443";
    .ssl = 1;               # Turn on SSL support
    .ssl_sni = 1;           # Use SNI extension  (default: 1)
    .ssl_verify_peer = 1;   # Verify the peer's certificate chain (default: 1)
    .ssl_verify_host = 1;   # Verify the host name in the peer's certificate (default: 0)
}

Coffelt