Bud - a TLS "swiss knife"

Wed Apr 02 2014 20:00:00 GMT-0400 (EDT)

Bud

To terminate TLS or not? Good question, but instead of answering it - I'll try to make you believe that if you need a TLS terminator - the Bud is just the right choice.

Other choices

Certainly, there are some other choices for TLS termination like:

  • stud
  • stunnel
  • nginx (though, not only a TLS terminator, but a web server too)
  • haproxy (much more than just a TLS terminator, but quite good!)
  • ...probably some others?

However, in many cases bud could do their job as well as they do and also provide some unique features.

Features

Speed

Bud is as fast as all of it rivals, here are comparison of it to stud:

Normal response:

Normal RPS Normal Response

Big response:

Big RPS Big Response

Asynchronous SNI and balancing

This is a killer feature for any serious PaaS offering an HTTPS access to the hosted applications. When enabled in configuration, on every incoming request bud will do an http query to receive a TLS certificate/key pair and an address of the backend to which this connection should be balanced.

See docs for details.

Asynchronous OCSP stapling

The same kind of thing could be used to perform OCSP stapling asynchronously, which is pretty useful if certificates are loaded dynamically and it isn't possible to store all of them in memory.

See docs for more details.

All that asynchronous APIs are JSON based, so replying to such requests is as easy as possible for almost any platform (including node.js).

X-Forwarded-For

The latest feature that I have implemented so far is an x-forward backend option. When enabled, bud will add X-Forwarded-For header to the first request of all incoming HTTP connections and send custom X_FORWARD frame for all SPDY connections.

This custom X_FORWARD frame is already supported in node-spdy@1.25.0 and will automatically add X-Forwarded-For header to all requests on that SPDY connection.

The main pros of this method is that no actual protocol parsing is happening. The cons is that, in case of HTTP protocol, only first request gets this header added. This could be worked around by checking this header on incoming request and associating it with a underlying socket (req.socket in node.js.)

Try it out!

Hearing all that awesome things - you may become interested in giving it a try, thanks to npm it is quite simple:

npm install -g bud-tls

Generating a configuration is easy too:

bud --default-config > config.json
vim config.json

All this options are documented in the project's readme.

Just in case, this blog is running behind bud!

Reporting issues

Something does not work as expected or just crashes? Please do not hesitate to report it on github issues.