14 January 2023

Recently, we managed to get secnet and hippotat into Debian. They are on track to go into Debian bookworm. This completes in Debian the set of VPN/networking tools I (and other Greenend) folks have been using for many years. The Sinister Greenend Organisation s suite of network access tools consists mainly of:

• secnet - VPN.
• hippotat - IP-over-HTTP (workaround for bad networks)
• userv ipif - user-created network interfaces

secnet secnet is our very mature VPN system. Its basic protocol idea is similar to that in Wireguard, but it s much older. Differences from Wireguard include:

• Comes with some (rather clumsy) provisioning tooling, supporting almost any desired virtual network topology. In the SGO we have a complete mesh of fixed sites (servers), and a number of roaming hosts (clients), each of which can have one or more sites as its home.
• No special kernel drivers required. Everything is userspace.
• An exciting polypath mode where packets are sent via multiple underlying networks in parallel, offering increased reliability for roaming hosts.
• Portable to non-Linux platforms.
• A much older, and less well audited, codebase.
• Very flexible configuration arrangements, but things are also under-documented and to an extent under-productised.
• Hasn t been ported to phones/tablets.

secnet was originally written by Stephen Early, starting in 1996 or so. I inherited it some years ago and have been maintaining it since. It s mostly written in C. Hippotat Hippotat is best described by copying the intro from the docs:

Hippotat is a system to allow you to use your normal VPN, ssh, and other applications, even in broken network environments that are only ever tested with web stuff . Packets are parcelled up into HTTP POST requests, resembling form submissions (or JavaScript XMLHttpRequest traffic), and the returned packets arrive via the HTTP response bodies.

It doesn t rely on TLS tunnelling so can work even if the local network is trying to intercept TLS. I recently rewrote Hippotat in Rust. userv ipif userv ipif is one of the userv utilities. It allows safe delegation of network routing to unprivileged users. The delegation is of a specific address range, so different ranges can be delegated to different users, and the authorised user cannot interfere with other traffic. This is used in the default configuration of hippotat packages, so that an ordinary user can start up the hippotat client as needed. On chiark userv-ipif is used to delegate networking to users, including administrators of allied VPN realms. So chiark actually runs at least 4 VPN-ish systems in production: secnet, hippotat, Mark Wooding s Tripe, and still a few links managed by the now-superseded udptunnel system. userv userv ipif is a userv service. That is, it is a facility which uses userv to bridge a privilege boundary. userv is perhaps my most under-appreciated program. userv can be used to straightforwardly bridge (local) privilege boundaries on Unix systems. So for example it can:

• Allow a sysadmin to provide a shell script to be called by unprivileged users, but which will run as root. sudo can do this too but it has quite a few gotchas, and you have to be quite careful how you use it - and its security record isn t great either.
• Form the internal boundary in a privilege-separated system service. So, for example, the hippotat client is a program you can run from the command line as a normal user, if the relevant network addresses have been delegated to you. On chiark, CGI programs run as the providing user - not using suexec (which I don t trust), but via userv.

userv services can be defined by the called user, not only by the system administrator. This allows a user to reconfigure or divert a system-provided default implementation, and even allows users to define and implement ad-hoc services of their own. (Although, the system administrator can override user config.) Acknowledgements Thanks for the help I had in this effort. In particular, thanks to Sean Whitton for encouragement, and the ftpmaster review; and to the Debian Rust Team for their help navigating the complexities of handling Rust packages within the Debian Rust Team workflow.

comments