« Blog Index
September 4, 2017

Caddy 0.10.7 Released with Secure Forward Proxy Plugin

By Matt Holt and Sergey Frolov

Caddy 0.10.7 was released two Fridays ago. There was no hype or celebration because technically it's a minor release. But this is a landmark release in more than one way. Most notably, a new plugin, http.forwardproxy, is a significant boon to those interested in online privacy and Internet freedom.

First, I want to thank the countless hours of effort that contributors have put into the project and its community. This particular release had 9 contributors to the code base: Simon Lightfoot, Dhananjay Balan, Dusty Doris, Henrique Dias, Mark Severson, Mattias Wadman, Sergey Frolov, Julian Mazzitelli, and Andreas Linz.

And community faithfuls like Francis Lavoie, Toby Allen, and Matthew Fay continue to engage in issues and forum posts. We hope you'll get involved, too!

Privacy-Preserving HTTP/2 Forward Proxy

Thanks to the new forwardproxy plugin, Caddy can act as a forward HTTPS proxy. To our knowledge, this is first plugin for web servers that supports HTTP/2 and forward proxying at the same time. That's why this plugin has many usability, performance, and privacy features, some of which are unique:

This plugin was designed and written by Sergey Frolov, a student researcher at the University of Colorado Boulder. Because this plugin might have positive implications for the privacy and freedom of potentially many users of the Internet, we wanted this to live in an official Caddy repository. The source code for this plugin can be found on GitHub.

You may find ways to configure your web browser to use a forward proxy in this blog post.

We hope that many users will be able to deploy forwardproxy and find it helpful in preserving their privacy in hostile network environments.

Graceful Binary Upgrades

For years now, Caddy has been able to reload its configuration with zero downtime upon SIGUSR1, but we hadn't implemented SIGUSR2... until now.

Sending SIGUSR2 to Caddy will invoke a graceful, zero-downtime binary upgrade. Simply replace the binary file on disk and then trigger the upgrade with the signal to apply changes. Unlike SIGUSR1, the Caddyfile will not be reloaded, so you can be assured that the same configuration will continue to be used, even if the Caddyfile changed on disk in the meantime.

This is the first major step toward automatic security and stability upgrades. In the future, we'll be designing and testing a system for safely rolling out minor updates to public-facing Caddy instances automatically. We believe this technology will help keep sites on the Web safe and secure as cipher suites are phased in or out, or bugs in the server are found and fixed. We still have some details to work out, but regardless: this won't be deployed until our comprehensive test suite is in place to ensure that upgrades are in fact non-breaking.

Plan 9 Support

It was easy enough, so why not. Thanks to the Go assembler and a few small tweaks to Caddy's code, you can now run Caddy on Plan 9! (*Tweee*)

Distinguishable Exit Codes

You've all been waiting for it, and finally, Caddy doesn't quit with the same exit code every time. Now, exit code 1 is only emitted if Caddy quits before the servers start listening. In other words, don't automatically restart after exit code 1. Caddy doesn't quit once it has started unless there is an intervention from the user, system, or environment; in those cases, Caddy will exit with a status code > 1. The docs describe the different codes.

AWS ES and Jekyll Plugins

Two more plugins are available with this release: http.awses and http.jekyll. The AWSES integration makes it easy to proxy requests to AWS ElasticSearch. The Jekyll plugin is like http.hugo but for Jekyll!

Smaller Things

We also fixed a few bugs and the community helped with quite a few little bothersome issues, so this is officially the best release yet! Thanks again to all who helped.

Are you using Caddy? Let the world know! Tweet about it, we'd love for people to know your experience.


« Blog Index