I started working with computers as a teenager; I did my first paid programming jobs at the age of 15. As soon as old enough to be legally self-employed, I started my own business "Brauer Software" while still going to school. Once I finished my formal schooling, I was able to earn a living from my programming work, writing custom software for companies ranging from small businesses to international enterprises.
In the late 90s I started BS Web Services (BSWS), an ISP serving hundreds of customers today. Starting an ISP from scratch required me to get deeply into all aspects of Internetwork technology: networking, mail, dns, webservers - and before it became fashionable, security. The interest in doing things properly and security soon brought me to OpenBSD, initially as a user of their operating system in our infrastructure. In 2002, I was asked to join the OpenBSD team as a developer. My first commit was a change to pf, OpenBSD's brand-new packet filter system.
I have since worked in most areas of OpenBSD, both updating existing and writing original code, and I did lots of work outside the OpenBSD project as well.
OpenBSD's Packet Filter, "pf", was the first area I worked on extensively in OpenBSD, and it is still where I do most of my work. Initially, I was working on adding features to and finding and fixing bugs in the still new PF, but as the system matured, this changed into improving the overall structure of PF. This increased drastically when fellow developer Ryan McBride and I, on a long ferry ride in Canada, started talking about if we were to do it all over, how we would design a packet filter from scratch. We came up with many good ideas, and a rough design evolved. We then discussed how to implement these changes over a number of years, as pf was an actively and commonly used product, and these changes had to be evolutionary, not revolutionary, and to be fit into OpenBSD's six month release cycle. Our original plan was to do this over a period of two, maybe three years -- actual implementation took from 2005 to early 2011. Needless to say, we learned a lot from this project -- we have redesigned and reimplemented about three-quarters of pf, and in the process, changed the way the OpenBSD project looks at pf -- not as an isolated component, but as an integral part of the operating system and network stack.
These fundamental changes to pf were introduced and implemented smoothly over time, while leaving the system always functional for users.
Most Internet Service Providers run BGP, the Border Gateway Protocol. This is how ISPs announce reachability and network paths to one another, in effect, a dynamically created map of the Internet. In 2003, I was unhappy enough with the BGP solution we used at BSWS, and started writing my own. OpenBGPD was added to the OpenBSD source tree in December, 2003, and with the help of a number of other OpenBSD developers, we quickly had it in a state which satisfied my needs.
These days OpenBGPD is a complete BGP implementation, and along with our many changes to the network stack, OpenBSD and OpenBGPD make for a wonderful BGP router and is being used all over the world by ISPs from local small providers to large multi-national, as well as many Internet Exchange Points (IXPs).
Inspired by dissatisfaction with the existing implementations, i took the framework i wrote for OpenBGPD and implemented the Network Time Protocol for OpenBSD - OpenNTPD. The first versions were minimalistic, simplicity is still a goal (do you want to work at configuring for ages, or do you just want your machine have accurate time?), but later versions gained much more accuracy - mostly by kernel side changes, another aspect of the "whole picture" approach I apply whenever possible.
OpenNTPD has been ported to many other operating systems and keeps clocks in sync on devices you wouldn't even guess contain a Unix-like system.
E-mail is used for more than just human-to-human communications, it is also used for machine to human and machine to machine communications. In many cases, a full-blown Mail Transport Agent (MTA) is way too much management effort - many systems just send their daily reports and maybe some activity output. Thus, something was needed that was simple and correct, with no local queues, which could be invoked as a standard mail transport agent, potentially within a secured web application environment, and just forwards the mail to a central mail server for actual delivery. After looking at the existing choices it was clear that all of them were so incredibly bad that I would never run them. I could not find a single "small" mail transport that implemented the relevant standards, most notably RFC2822, sufficiently well. In fact, it seems they work more by accident than design. Thus, I wrote my own -- femail. Today, femail is widely used, having been ported to many different operating systems.
good, secure programming
Internet security, while recently becoming a big concern for the corporate world, has been a personal concern for well over a decade. It is not about making things work, it is about making them work well and correctly.
Security is a natural side-effect of doing things right. Good software is designed with quality and security as part of the design, not an afterthought.
Applications exposed to the Internet obviously have critical security needs, in todays "connected" world, very little is not exposed to the Big Bad Internet. Even applications behind firewalls are exposed to compromised users' computers and users with malicious intent. To this date, exploitable bugs have not been found in any of the applications I have written.
There are many aspects to Doing Things Right, leading to secure code, but here are a few:
- Properly and completely sanitizing both user and application input data
- Privilege dropping/Privilege separation
- Structuring to contain unplanned failures
- Clean code that others can effectively review
In addition to practicing these techniques, I teach them. I have spoken at conferences and universities about these topics, and continue to do so. Every compromised computer being used as a remotely controlled zombie in a DDoS attack or a spam or porn distribution system is at best annoying, but often an active threat to the community (including me!), and the Internet infrastructure, including ISPs.