Tag: encryption

For those of you who depend on Varnish to offer robust caching and scaling potential to your web stack, hearing about Google’s prioritization (albeit arguably small, for now) of sites that force SSL may cause pause in how to implement.

Varnish currently doesn’t have the ability to handle SSL certificates and encrypt requests as such. It may never actually have this ability because its focus is to cache content and it does a very good job I might add.

So if Varnish can’t handle the SSL traffic directly, how would you go about implementing this with Nginx?

Well, nginx has the ability to proxy traffic. This is one of the many reasons why some admins choose to pair Varnish with Nginx. Nginx can do reverse proxying and header manipulation out of the box without custom modules or configuration. Combine that with the lightweight production tested scalability of Nginx over Apache and the reasons are simple. We’re not interested in that debate here, just a simple implementation.

Nginx Configuration

With Nginx, you will need to add an SSL listener to handle the ssl traffic. You then assign your certificate. The actual traffic is then proxied to the (already set up) non-https listener (varnish).

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

server{

listenx.x.x.x:443ssl;

server_name yoursite.com www.yoursite.com;

ssl_certificate/etc/nginx/ssl/yoursite.com.crt;

ssl_certificate_key/etc/nginx/ssl/yoursite.com.key;

ssl_protocols TLSv1 TLSv1.1TLSv1.2;

ssl_ciphers HIGH:!aNULL:!MD5;

if($host!~*^www.){

rewrite^(.*)$https://www.$host$1 permanent;

}

location/{

# Pass the request on to Varnish.

proxy_pass http://127.0.0.1:80;

# Pass some headers to the downstream server, so it can identify the host.

proxy_set_header Host$host;

proxy_set_headerX-Real-IP$remote_addr;

proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;

# Tell any web apps like Drupal that the session is HTTPS.

proxy_set_headerX-Forwarded-Proto https;

proxy_redirect off;

}

}

The one thing to note before going further is the second last line of the configuration. That is important because it allows you to avoid an infinite redirect loop of a request proxying to varnish, varnish redirecting non-ssl to ssl and back to nginx for a proxy. You’ll notice that pretty quickly because your site will ultimately go down 🙁

What nginx is doing is defining a custom HTTP header and assigning a value of “https” to it :

1

proxy_set_headerX-Forwarded-Proto https;

So the rest of the nginx configuration can remain the same (the configuration that varnish ultimately forwards requests in order to cache).

Varnish

What you’re going to need in your varnish configuration is a minor adjustment :

1

2

3

4

if(req.http.X-Forwarded-Proto!~"(?i)https"){

set req.http.x-Redir-Url="https://www.yoursite.com"+req.url;

error750req.http.x-Redir-Url;

}

What the above snippet is doing is simply checking if the header “X-Forwarded-Proto” (that nginx just set) exists and if the value equals (case insensitive) to “https”. If that is not present or matches , it sets a redirect to force the SSL connection which is handled by the nginx ssl proxy configuration above. Its also important to note that we are not just doing a clean break redirect, we are still appending the originating request URI in order to make it a smooth transition and potentially not break any previously ranked links/urls.

The last thing to note is the error 750 handler that handles the redirect in varnish :

1

2

3

4

5

6

7

subvcl_error{

if(obj.status==750){

set obj.http.Location=obj.response;

set obj.status=302;

return(deliver);

}

}

You can see that were using a 302 temporary redirect instead of a permanent 301 redirect. This is your decision though browsers tend to be stubborn in their own internal caching of 301 redirects so 302 is good for testing.

After restarting varnish and nginx you should be able to quickly confirm that no non-SSL traffic is allowed anymore. You can not only enjoy the (marginal) SEO “bump” but you are also contributing to the HTTPS Everywhere movement which is an important cause!

With the advent of cloud computing, there have been several advances as far as commercial cloud offerings, most notably Amazon’s EC2 computing platform as well as their S3 Storage platform.

Backing up to Amazon S3 has become a popular alternative to achieving true offsite backup capabilities for many organizations.

The fast data transfer speeds as well as the low cost of storage per gigabyte make it an attractive offer.

There are several free software solutions that offer the ability to connect to S3 and transfer files. The one that shows the most promise is s3sync.

There are already a few guides that show you how to implement s3sync on your system.

The good thing is that this can be implemented in Windows, Linux, FreeBSD among other operating systems.

We have written a simple script that utilizes the s3sync program in a scheduled offsite backup scenario. Find our script below, and modify it as you wish. Hopefully it will help you get your data safely offsite 😉

SuperSTAR SUPPORT

Stack Star will provide a minimum 99.99% uninterrupted access to your web site, email, VPS and other related services. Should your services become unavailable for a cumulative period beyond the allowed 0.01% in any month of service, the client will receive a credit equivalent to 5% of the client’s pro-rated recurring monthly fees for that month and then an additional 5% for every additional 15 minutes the web site and/or other related services are unavailable.