Back to main menu

Product

Weekly product update: Tips for configuring SSL termination on Cloud Load Balancers

We hope that the next time you need to add SSL termination to your load balancers, you'll find this information useful. Read more...

PUBLISHED ON

PUBLISHED ON

We like to keep you up-to-date with what’s happening at Mailgun each week, but sometimes the projects we’re working on are all in the Research & Development phases and we don’t have much to share. That happened this week, so nothing big to report. But that doesn’t mean we haven’t been busy. Since Mailgun customers are developers like us, we thought we would share what we learned doing a common maintenance task: adding SSL termination to our Cloud Load Balancers that handle control panel and website traffic. We found some interesting things, especially around performance, that may be of use in your own application. If that’s not your thing, don’t worry, come back next week for more new features and improvements.

Adding SSL termination to Rackspace Cloud Load Balancers

A common requirement for SaaS providers (like Mailgun and many of our customers) is to keep track of sessions by IP address. When passing traffic through a load balancer, there are different ways to make sure that original IP address is perserved. In the past, we used an F5 load balancer which passes a $remoteaddr variable that we used in our nginx config. This variable was a client’s address taken from socket options. When we recently moved to Rackspace Cloud Load Balancers to serve traffic for our website and control panel, we noticed that Cloud Load Balancers provide the load balancer’s IP for $remoteaddr, instead of the client’s IP address. So we needed another way to perserve this information.

Cloud Load Balancers can add a X-Forwarded-For header with client’s IP value, however this option doesn’t work for SSL which we use for our control panel. Why wouldn’t it work? Simple. In order to add a header to the file sent over SSL, the load balancer first needs to decrypt the file. By default, a load balancer is not equipped to do this and the header is not added. Luckily, Cloud Load Balancers offers an SSL termination option that allows you to decrypt SSL traffic before passing it to the destination servers. It has certain advantages around reducing load on application servers. To make it work you just need to enable SSL termination for your load balancer and provide it with an SSL private key and certificate.

This is actually a cool example of separation of concerns. Instead of having all SSL related stuff in your server configuration files,you put it into the load balancer and it just works.

An important thing you should keep in mind is that after you enable SSL termination, all the HTTPS traffic coming through the load balancer will become HTTP. It seems obvious, yet it’s pretty common to forget about this little detail. We actually ran into this issue ourselves when testing on our staging environment. The solution is to use X-Forwarded-Proto header that the load balancer sets to “https” for HTTPS traffic. Here is a good example of how you do it in nginx.

A surprising performance result using SSL termination

Before we implemented the change, we wanted to make sure that performance didn’t suffer when using SSL termination. To check for this, we ran some performance tests on our staging environment and got some unexpected results: load-balancers with ssl termination actually performed better on average than load-balancers without it.

To run the rest, we performed a GET on three different URLs:

  • Badge Check

    GET /cp

  • Badge Check

    GET /cp/log

  • Badge Check

    GET /cp/domains[/list]

Each GET retrieved HTML pages with and without all embedded resources i.e. parse the HTML file and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file.

While there was one instance where performance with SSL was slower, on average performance was surprising better: reducing average load time from 3957 milliseconds to 3811 milliseconds, a decrease of 3.7%. Not bad considering that SSL termination adds steps to the process of transferring a file from the client to the server and back.

That’s it for this week. We hope that the next time you need to add SSL termination to your load balancers, you’ll find this information useful. Till next week.

Happy emailing,

The Mailgunners

Related readings

How to improve your email deliverability for the future of email

If your customers aren’t getting your emails, then there’s a good chance that your email program needs some refreshing with these email deliverability tips taken from Email Camp: MessageMania speaker and industry pro, Laura Atkins.

Read More

Announcing new analytics features to maximize your email performance

Navigating email analytics has never been easier than with our latest updates. Advanced data analysis, faster performance, and better data management tools have been released...

Read More

An expanded Mailgun product suite to transform email deliverability

Today marks a special day for Sinch Mailgun. For over a decade, our focus has been to provide the best email experience for businesses all around the world. Now, we take...

Read More

Popular posts

Email inbox.

Email

5 min

Build Laravel 11 email authentication with Mailgun and Digital Ocean

Read More

Mailgun statistics.

Product

4 min

Sending email using the Mailgun PHP API

Read More

Statistics on deliverability.

Deliverability

5 min

Here’s everything you need to know about DNS blocklists

Read More

See what you can accomplish with the world's best email delivery platform. It's easy to get started.Let's get sending
CTA icon