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.

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.