Introducing Teleport

I'm happy to introduce Teleport, a new open source platform for managing SSH infrastructure. Teleport is built by Gravitational, a Y Combinator company that ships SaaS on any platform. While I'm not a part of Gravitational, I have been advising them on the Teleport project.

Most teams don't have a great authentication story. Some rely on passing passwords around haphazardly, while others rely on copying everyone's ~/.ssh/ to every new box. More complex homegrown systems quickly become unwieldy. These methods are problematic both operationally and from a security perspective: when security and usability are at odds, security tends to lose out. For a lot of teams, a single compromised key off of a developer machine spells disaster, on-boarding new team members is painful, and key rotation doesn't happen.

In the last few years, strong multi-factor authentication has become the norm. Tokens are only valid for a brief period of time, use challenge-response protocols, or both. Teleport helps bring the same level of sophistication to infrastructure. It helps system administrators leverage the security benefits of short-lived certificates, while keeping the operational benefits of decoupling server authentication from user authentication. It lets you run isolated clusters, so that a compromise of staging credentials doesn't lead to a compromise in production. It automatically maintains clear audit logs: who logged in, when and where they logged in, and what they did once they got there.

Teleport comes with a beautiful, usable UI, making it easy to visualize different clusters and the available machines within them. The UI is optional: many system administrators will prefer to use their existing SSH client, and Teleport supports that natively. Because it implements the SSH_AUTH_SOCK protocol, integrating your current CLI workflow is a simple matter of setting a single environment variable.

As someone with an open-source background, I'm glad to see this software released and developed out in the open. A decent SSH key management story should be available to everyone, and that's what Teleport does. I believe making this technology more accessible is good for everyone, including commercial vendors. Democratizing a decent DIY story helps turn their product into the battle-hardened and commercially supported version of industry best practice; and as such, I hope this helps grow that market. As a principal engineer at Rackspace Managed Security, I'm excited to start working towards better authentication stories, both internally and for our customers, with Teleport as the new baseline.

Releasing early and often is also an important part of open source culture. That can be at odds with doing due diligence when releasing security-critical systems like Teleport, especially when those systems have non-trivial cryptographic components. We feel Teleport is ready to show to the public now. To make sure we act as responsibly as possible, I've helped the Teleport team to join forces with a competent independent third-party auditor. We're not recommending that you bet the farm on Teleport by running it in production as your only authentication method just yet, but we do think it's ready for motivated individuals to start experimenting with it.

Some people might feel that a better SSH story means you're solving the wrong problem. It seems at odds with the ideas behind immutable infrastructure and treating servers as cattle, not pets. I don't think that's true. Firstly, even with immutable infrastructure, being able to SSH into a box to debug and monitor is still incredibly important. Being able to rapidly deploy a bunch of fixed images quickly may be good, but you still have to know what to fix first. Secondly, existing systems don't always work that way. It may not be possible, let alone economically rational, to "port" them effectively. It's easy to think of existing systems as legacy eyesores that only exist until you can eradicate them, but they do exist, they're typically here to stay, and they need a real security story, too.

Teleport is still in its early stages. It's usable today, and I'm convinced it has a bright future ahead of it. It's written in a beautiful, hackable Go codebase, and available on Github starting today.

Don't expose the Docker socket (not even to a container)

Docker primarily works as a client that communicates with a daemon process (dockerd). Typically that socket is a UNIX domain socket called /var/run/docker.sock. That daemon is highly privileged; effectively having root access. Any process that can write to the dockerd socket also effectively has root access.

This is no big secret. Docker clearly documents this in a bunch of places, including the introductory documentation. It's an excellent reason to use Docker Machine for development purposes, even on Linux. If your regular user can write to the dockerd socket, then every code execution vulnerability comes with a free privilege escalation.

The warnings around the Docker socket typically come with a (sometimes implicit) context of being on the host to begin with. Write access to the socket as an unprivileged user on the host may mean privileged access to the host, but there seems to be some confusion about what happens when you get write access to the socket from a container.

The two most common misconceptions seem to be that it either doesn't grant elevated privileges at all, or that it grants you privileged access within the container (and without a way to break out). This is false; write access to the Docker socket is root on the host, regardless on where that write comes from. This is different from Jerome Pettazoni's dind, which gives you Docker-in-Docker; we're talking about access to the host's Docker socket.

The process works like this:

  1. The Docker container gets a docker client of its own, pointed at the /var/run/docker.sock.
  2. The Docker container launches a new container mounting / on /host. This is the host root filesystem, not the first container.
  3. The second container chroots to /host, and is now effectively root on the host. (There are a few differences between this and a clean login shell; for example, /proc/self/cgroups will still show Docker cgroups. However, the attacker has all of the permissions necessary to work around this.)

This is identical to the process you'd use to escalate from outside of a container. Write access to the Docker socket is root on the host, full stop; who's writing, or where they're writing from, doesn't matter.

Unfortunately, there are plenty of development teams unaware of this property. I recently came across one, and ended up making a screencast to unambiguously demonstrate the flaw in their setup (which involved a container with write access to the Docker socket).

This isn't new; it's been a known property of the way Docker works ever since the (unfortunately trivially cross-site scriptable) REST API listening on a local TCP port was replaced with the /var/run/docker.sock UNIX domain socket.

querySelectorAll from an element probably doesn't do what you think it does

Modern browsers have APIs called querySelector and querySelectorAll. They find one or more elements matching a CSS selector. I'm assuming basic familiarity with CSS selectors: how you select elements, classes and ids. If you haven't used them, the Mozilla Developer Network has an excellent introduction.

Imagine the following HTML page:

<!DOCTYPE html>
    <img id="outside">
    <div id="my-id">
        <img id="inside">
        <div class="lonely"></div>
        <div class="outer">
            <div class="inner"></div>

document.querySelectorAll("div") returns a NodeList of all of the <div> elements on the page. document.querySelector("div.lonely") returns that single lonely div.

document supports both querySelector and querySelectorAll, letting you find elements in the entire document. Elements themselves also support both querySelector and querySelectorAll, letting you query for elements that are descendants of that element. For example, the following expression will find images that are descendants of #my-id:


In the sample HTML page above, it will find <img id="inside"> but not <img id="outside">.

With that in mind, what do these two expressions do?

document.querySelectorAll("#my-id div div");
document.querySelector("#my-id").querySelectorAll("div div");

You might reasonably expect them to be equivalent. After all, one asks for div elements inside div elements inside #my-id, and the other asks for div elements inside div elements that are descendants of #my-id. However, when you look at this JSbin, you'll see that they produce very different results:

document.querySelectorAll("#my-id div div").length === 1;
document.querySelector("#my-id").querySelectorAll("div div").length === 3;

What is going on here?

It turns out that element.querySelectorAll doesn't match elements starting from element. Instead, it matches elements matching the query that are also descendants of element. Therefore, we're seeing three div elements: div.lonely, div.outer, div.inner. We're seeing them because they both match the div div selector and are all descendants of #my-id.

The trick to remembering this is that CSS selectors are absolute. They are not relative to any particular element, not even the element you're calling querySelectorAll on.

This even works with elements outside the element you're calling querySelectorAll on. For example, this selector:

document.querySelector("#my-id").querySelector("div div div")

... matches div.inner in this snippet (JSbin):

<!DOCTYPE html>
      <div id="my-id">
        <div class="inner"></div>

I think this API is surprising, and the front-end engineers I've asked seem to agree with me. This is, however, not a bug. It's how the spec defines it to work, and browsers consistently implement it that way. Safari. John Resig commented how he and others felt this behavior was quite confusing back when the spec came out.

If you can't easily rewrite the selector to be absolute like we did above, there are two alternatives: the :scope CSS pseudo-selector, and query/queryAll.

The :scope pseudo-selector matches against the current scope. The name comes from the CSS scoping, which limits the scope of styles to part of the document. The element we're calling querySelectorAll on also counts as a scope, so this expression only matches div.inner:

document.querySelector("#my-id").querySelectorAll(":scope div div");

Unfortunately, browser support for scoped CSS and the :scope pseudo-selector is extremely limited. Only recent versions of Firefox support it by default. Blink-based browsers like Chrome and Opera require the well-hidden experimental features flag to be turned on. Safari has a buggy implementation. Internet Explorer doesn't support it at all.

The other alternative is element.query/queryAll. These are alternative methods to querySelector and querySelectorAll that exist on DOM parent nodes. They also take selectors, except these selectors are interpreted relative to the element being queried from. Unfortunately, these methods are even more obscure: they are not referenced on MDN or, and are missing from the current DOM4 working draft, dated 18 June 2015. They were still present in an older version, dated 4 February 2014, as well as in the WHATWG Living Document version of the spec. They have also been implemented by at least two polyfills:

In conclusion, the DOM spec doesn't always necessarily do the most obvious thing. It's important to know pitfalls like these, because they're difficult to discover from just the behavior. Fortunately, you can often rewrite your selector so that it isn't a problem. If you can't, there's always a polyfill to give you the modern API you want. Alternatively, libraries like jQuery can also help you get a consistent, friendly interface for querying the DOM.

Today's OpenSSL bug (for techies without infosec chops)

What happened?

OpenSSL 1.0.1n+ and 1.0.2b+ had a new feature that allows finding an alternative certificate chain when the first one fails. The logic in that feature had a bug in it, such that it didn't properly verify if the certificates in the alternative chain had the appropriate permissions; specifically, it didn't check if those certificates are certificate authorities.

Specifically, this means that an attacker who has a valid certificate for any domain, can use that certificate to produce new certificates. Those normally wouldn't work, but the algorithm for finding the alternative trust chain doesn't check if the valid certificate can act as a certificate authority.

What's a certificate (chain)?

A certificate is a bit like an ID card: it has some information about you (like your name), and is authenticated by a certificate authority (in the case of an ID, usually your government).

What's a certificate authority?

A certificate authority is an entity that's allowed to authenticate certificates. Your computer typically ships with the identity of those certificate authorities, so it knows how to recognize certificates authorized by them.

In the ID analogy, your computer knows how to recognize photo IDs issued by e.g. California.

The issue here is that in some cases, OpenSSL was willing to accept signatures authenticated by certificates that don't have certificate authority powers. In the analogy, it would mean that it accepted CostCo cards as valid ID, too.

Why did they say it wouldn't affect most users?

This basically means "we're assuming most users are using OpenSSL for vanilla servers", which is probably true. Most servers do use OpenSSL, and most clients (browsers) don't.

The bug affects anyone trying to authenticate their peer. That includes regular clients, and servers doing client authentication. Regular servers aren't affected, because they don't authenticate their peer.

Servers doing client authentication are fairly rare. The biggest concern is with clients. While browsers typically don't use OpenSSL, a lot of API clients do. For those few people affected by the bug and with clients that use OpenSSL, the bug is catastrophic.

What's client authentication?

The vast majority of TLS connections only authenticate the server. When the client opens the connection, the server sends its certificate. The client checks the certificate chain against the list of certificate authorities that it knows about. The client is typically authenticated, but over the protocol spoken inside of TLS (usually HTTP), not at a TLS level.

That isn't the only way TLS can work. TLS also supports authenticating clients with certificates, just like it authenticates servers. This is called mutually authenticated TLS, because both peers authenticate each other. At Rackspace Managed Security, we use this for all communication between internal nodes. We also operate our own certificate authority to sign all of those certificates.

What's TLS?

TLS is what SSL has been called for way over a decade. The old name stuck (particularly in the name "OpenSSL"), but you should probably stop using it when you're talking about the secure protocol, since all of the versions of the protocol that were called "SSL" have crippling security bugs.

Why wasn't this found by automated testing?

I'm not sure. I wish automated testing this stuff was easier. Since I'm both a user and a big fan of client authentication, which is a pretty rare feature, I hope to spend more time in the future creating easy-to-use automated testing tools for this kind of scenario.

How big is the window?

1.0.1n and 1.0.2b were both released on 11 Jun 2015. The fixes, 1.0.1p and 1.0.2d, were released today, on 9 Jul 2015.

The "good news" is that the bad releases are recent. Most people who have an affected version will be updating regularly, so the number of people affected is small.

The bug affected following platforms (non-exhaustive):

  • It did not affect stock OS X, because they still ship 0.9.8. However, the bug does affect a stable version shipped through Homebrew (1.0.2c).
  • Ubuntu is mostly not affected. The only affected version is the unreleased 15.10 (Wily). Ubuntu has already released an update for it.
  • The bug affects stable releases of Fedora. I previously mistakenly reported that the contrary, but that information was based on their package version numbers, which did not match upstream. Fedora backported the faulty logic to their version of 1.0.1k, which was available in Fedora 21 and 22. They have since released patches; see this ticket for details. Thanks to Major Hayden for the correction!
  • The bug does not affect Debian stable, but it does affect testing and unstable.
  • The bug affects ArchLinux testing.

In conclusion

The bug is disastrous, but affects few people. If you're running stable versions of your operating system, you're almost certainly safe.

The biggest concern is with software developers using OS X. That audience uses HTTPS APIs frequently, and the clients to connect to those APIs typically use OpenSSL. OS X comes with 0.9.8zf by default now, which is a recent revision of an ancient branch. Therefore, people have a strong motivation to get their OpenSSL from a third-party source. The most popular source is Homebrew, which up until earlier this morning shipped 1.0.2c. The bug affects that version. If you installed OpenSSL through Homebrew, you should go update right now.

They do take security seriously

Earlier today, I read an article about the plethora of information security breaches in recent history. Its title reads:

“We take security seriously”, otherwise known as “We didn’t take it seriously enough”

The article then lists a number of companies informing the public that they've been breached.

I think this article doesn't just blame the victims of those attacks, but subjects them to public ridicule. Neither helps anyone, least of all end users.

I'm surprised to hear such comments from Troy Hunt. He's certainly an accomplished professional with extensive security experience. This is not the first time people have expressed similar thoughts; the HN thread for that article is rife with them.

The explicit assumption is that these companies wouldn't have gotten in trouble if only they had taken security more seriously. In a world where the information services store is increasingly valuable and software increasingly complex, breaches are going to happen. The idea that getting breached is their own darn fault is unrealistic.

This idea is also counterproductive. Firstly, there's one thing all of the victims being ostracized have in common: they disclosed the details of the breach. That is exactly what they should have done; punishing them creates a perverse incentive for victims to hide breaches in the future, a decidedly worse end-user outcome.

Secondly, if any breach is as bad as any other breach, there is no incentive to proactively mitigate damage from future breaches by hardening internal systems. Why encrypt records, invest in access control or keep sensitive information in a separate database with extensive audit logging? It might materially impact end-user security, but who cares -- all anyone is going to remember is that you got popped.

Finally, there's a subtle PR issue: how can the security industry build deep relationships with clients when we publicly ridicule them when the inevitable happens?

These commentators have presumably not been the victims of a breach themselves. I have trouble swallowing that anyone who's been through the terrifying experience of being breached, seeing a breach up close or even just witnessing a hairy situation being defused could air those thoughts.

If you haven't been the victim of an attack, and feel that your security posture is keeping you from becoming one, consider this:

  1. What's your threat model?
  2. How confident are you in your estimation of the capabilities of attackers?
  3. Would you still be okay if your database became three orders of magnitude more valuable? Most personal data's value will scale linearly with the number of people affected, so if you're a small start-up with growth prospects, you'll either fail to execute, or be subject to that scenario.
  4. Would you still be okay if the attacker has a few 0-days?
  5. What if the adversary is a nation-state?
  6. How do you know you haven't been breached?

That brings me to my final thesis: I contest the claim that all of the companies in the article didn't take security seriously. It is far more probable that all of the companies cited in the article have expended massive efforts to protect themselves, and, in doing so, foiled many attacks. It's also possible that they haven't; but the onus there is certainly on the accuser.

Clearly, that's a weak form of disagreement, since "taking something seriously" is entirely subjective. However, keep in mind that many targets actually haven't taken security seriously, and would not even have the technical sophistication to detect an attack.

(By the way, if you too would like to help materially improve people's security, we're hiring. Contact me at [email protected].)

HTTPS requests with client certificates in Clojure

The vast majority of TLS connections only authenticate the server. When the client opens the connection, the server sends its certificate. The client checks the certificate against the list of certificate authorities that it knows about. The client is typically authenticated, but over the inner HTTP connection, not at a TLS level.

That isn't the only way TLS can work. TLS also supports authenticating clients with certificates, just like it authenticates servers. This is called mutually authenticated TLS, because both peers authenticate each other. At Rackspace Managed Security, we use this for all communication between internal nodes. We also operate our own certificate authority to sign all of those certificates.

One major library, http-kit, makes use of Java's, notably SSLContext and SSLEngine. These Java APIs are exhaustive, and very... Java. While it's easy to make fun of these APIs, most other development environments leave you using OpenSSL, whose APIs are patently misanthropic. While some of these APIs do leave something to be desired, aphyr has done a lot of the hard work of making them more palatable with less-awful-ssl. That gives you an SSLContext. Request methods in http-kit have an opts map that you can pass a :sslengine object to. Given an SSLContext, you just need to do (.createSSLEngine ctx) to get the engine object you want.

Another major library, clj-http, uses lower-level APIs. Specifically, it requires [KeyStore][keystore] instances for its :key-store and :trust-store options. That requires diving deep into Java's cryptographic APIs, which, as mentioned before, might be something you want to avoid. While clj-http is probably the most popular library, if you want to do fancy TLS tricks, you probably want to use http-kit instead for now.

My favorite HTTP library is aleph by Zach Tellman. It uses Netty instead of the usual Java IO components. Fortunately, Netty's API is at least marginally friendlier than the one in Unfortunately, there's no less-awful-ssl for Aleph. Plus, since I'm using sente for asynchronous client-server communication, which doesn't have support for aleph yet. So, I'm comfortably stuck with http-kit for now.

In conclusion, API design is UX design. The library that "won" for us was simply the one that was easiest to use.

For a deeper dive in how TLS and its building blocks work, you should watch my talk, Crypto 101, or the matching book. It's free! Oh, and if you're looking for information security positions (that includes entry-level!) in an inclusive and friendly environment that puts a heavy emphasis on teaching and personal development, you should get in touch with me at [email protected].

Call for proposal proposals

I'm excited to announce that I was invited to speak at PyCon PL. Hence, I'm preparing to freshen up my arsenal of talks for the coming year. The organizers have very generously given me a lot of freedom regarding what to talk about.

I'd like to do more security talks as well as shift focus towards a more technical audience, going more in-depth and touching on more advanced topics.


Object-capability systems

Capabilities are a better way of thinking about authorization. A capability ("cap") gives you the authority to perform some action, without giving you any other authority. Unlike role-based access control systems, capability based systems nearly always fail-closed; if you don't have the capability, you simply don't have enough information to perform an action. Contrast this with RBAC systems, where authorization constraints are enforced with pinky swears, and therefore often subverted.

I think I can make an interesting case for capability systems to any technical audience with some professional experience. Just talk about secret management, and how it's nearly always terrifying! This gives me an opportunity to talk about icecap (docs) and shimmer (blog, my favorite pastimes.

Putting a backdoor in RDRAND

I've blogged about this before before, but I think I could turn it into a talk. The short version is that Linux's PRNG mixes in entropy from the RDRAND in a way that would allow a malicious implementation to control the output of the PRNG in ways that would be indistinguishable to a (motivated) observer.

As a proof of concept, I'd love to demo the attack, either in software (for example, with QEMU) or even in hardware with an open core. I could also go into the research that's been done regarding hiding stuff on-die. Unfortunately, the naysayers so far have relied on moving the goalposts continuously, so I'm not sure that would convince them this is a real issue.


An opportunity to get in touch with my languishing inner electrical engineer! It turns out that when you zap radio waves at most hardware, the reflection gets modulated based on what it's doing right now. The concept became known as TEMPEST, an NSA program. So far, there's little public research on how feasible it is for your average motivated hacker. This is essentially van Eck phreaking, with 2015 tools. There's probably some interesting data to pick off of USB HIDs, and undoubtedly a myriad of interesting devices controlled by low-speed RS-232. Perhaps wireless JTAG debugging?

The unfinished draft bin

Underhanded curve selection

Another talk in the underhanded cryptography section I've considered would be about underhanded elliptic curve selection. Unfortunately, bringing the audience up to speed with the math to get something out of it would be impossible in one talk slot. People already familiar with the math are also almost certainly familiar with the argument for rigid curves.

Web app authentication

Some folks asked for a tutorial on how to authenticate to web apps. I'm not sure I can turn that into a great talk. There's a lot of general stuff that's reasonably obvious, and then there's highly framework-specific stuff. I don't really see how I can provide a lot of value for people's time.


David Reid and Dwayne Litzenberger made similar, excellent points. They both recommend talking about object-capability systems. Unlike the other two, it will (hopefully) actually help people build secure software. Also, the other two will just make people feel sad. I feel like those points generalize to all attack talks; are they just not that useful?

Everything I've learned about running a financial aid program

For the past two years, I've been running PyCon's financial aid program. Starting this year, the event coordinator has asked all staff members to document what they do for PyCon. Firstly, this helps to objectively recognize the hard work done by our (volunteer) staff, and to help make sure there is continuity when the time comes to pass the torch. Since organizers of other conferences have expressed interest in my opinions for creating their own financial aid programs, I am posting my notes publicly instead.

This is a collection of hard-earned opinions, and is very much work in progress. It's written as if it were a conversation with a hypothetical financial aid organizer; so, whenever I say "you", I mean you, the awesome person running financial aid at a conference somewhere.


Financial aid programs are one of the most effective ways a software foundation can spend their money. Even if you completely ignore the effect it has on diversity, the number of speakers, sprinters and other contributors that attended PyCon thanks to the financial aid program is staggering.

Naming your program

I inherited the term "Financial Aid". It's a fine term, but some other conferences have come up with different terms that you may want to consider, like "opportunity grants" and "diversity grants".

Taking care of yourself

Running a financial aid program is a lot of work. It scales linearly with the number of applicants; it's your job to create a process that keeps the work per applicant small, so that you can make the number of applicants large. (You'll know you've succeeded when the fixed overhead dominates, and it wouldn't really matter if you added another dozen people.)

It is also an exercise in deferred gratification. Typically, you will need to start preparing about a year before the conference. The gratification part only comes at the conference itself. Since you'll probably be quite busy as an organizer, it may only come after the conference is over. You probably want to make sure that you have an excellent social circle and that you're fairly self-motivated.

As the Financial Aid Chair, I have been on the receiving end of verbal abuse once. Don't put up with it.

Beat the drum

Your financial aid program is useless if people don't know about it.

Some very talented speakers refrain from sending talk proposals because they don't know if they can afford to attend.


PyCon's financial aid program is quite large. There are a number of reasons for that:

  • PyCon's financial aid program has been around for many years, so it's quite mature.
  • The program can count on support from PyCon leadership and the Python Software Foundation.
  • Because PyCon US is the largest PyCon in the world, it acts as a nexus for people across the globe; therefore, it's important for the Python community that as many people as possible have a chance to attend.

This is just to give you a ballpark idea of our numbers.

Regardless of what your numbers will be, expect that the primary bottleneck of your financial aid program will simply be lack of funds.

Confusing parts and sad truths


A lot of people will not show up, and not notify you (or notify you in the days around the conference). Sometimes, there's good reasons (illness, emergencies...). Sometimes, the reasons are less great. Sometimes, you won't know the reason.

From the perspective of the Financial Aid Chair, no-shows are terrible. It's a dead grant: money that's been allocated that can't easily be translated into an extra attendee. Hence, many of the suggestions I make for running financial aid processes are focused on minimizing no-shows.

Visas and travel

Many recipients have to cancel because they are unable to acquire visas to Canada or the United States. In some cases, the visa process took several months and simply did not complete in time for the conference. In others the visas were declined for various reasons.

Occam's razor tells me that many countries, particularly the United States, to some extent now Canada, but also Schengen zone countries are simply actively hostile to foreigners visiting their country.


Stand by your Chair

At the end of the day, someone's responsible for making your conference all it can be. That position is typically called the Conference Chair. They get help from teams like the Program Committee and Financial Aid to make that happen. At the end of the day they make the hard calls, and you have to execute within their guidelines. That typically includes the budget, but it also includes how you want to allocate grants. You will almost certainly be resource-constrained, so there are trade-offs to be made:

  • Do you want to help newbies, or advanced programmers?
  • Do you want to help marginalized groups? Which ones? How much?
  • Do you want repeat attendees, or first timers?
  • Do you want a few people from all over the globe, or many locals?
  • Do you want to benefit people who directly contribute to the conference? Which ones (speakers, staff...)? How much?
  • Do we care if people are receiving funds from other places? What if their employer is paying? What if their employer is also a sponsor? Does it make sense for them to give us x sponsorship fees when we're giving them a significant portion of that back in financial aid?

Your budget is, unfortunately, zero sum. Every group you benefit means less for everyone else. Helping everyone is the same as helping no-one. Everyone wants to help everyone, but it's unlikely you'll get to do that. Make everyone understands exactly what you want to accomplish; you don't want to have this argument in the middle of trying to run a financial aid process.

Free or reduced-price tickets

For many conferences, the tickets themselves can be quite expensive. It makes sense to provide them to financial aid recipients at no (or reduced) charge as part of their grant.

PyCon previously provided free registration, but now provides reduced-cost registration. This helps with no-shows, giving applicants a financial incentive to let you know if they can't attend.

Make sure that you document clearly that people will be receiving tickets, at what price they'll be receiving them, and that their spots are reserved. Common concerns from financial aid applicants:

  • "Your conference blog says that you're sold out, and I haven't received financial aid yet. Will I be able to attend?"
  • "I've already registered to reserve my spot; what do I do now that I get financial aid?"
  • "I'm a student. Will I still be able to register at the student rate if I apply for financial aid?"
  • "I applied for a larger amount because I didn't think ticket price would be included." (Unfortunately, most people tell you this far too late.)

As usual, clarity in communication is key here.

Previous years, PyCon optionally provided free registration for people who asked. This optional part was somewhat confusing. Whatever you do, make it part of the default grant application. That also means that you should probably offer the reduced-price ticket to anyone who applies for financial aid, even if you can't otherwise give them a grant. Otherwise, someone who applies for financial aid for whom you simply don't have enough funds will get punished twice: no financial aid, and no access to early bird ticket price.


Housing, in the context of financial aid, means that you pay for a bunch of hotel rooms for various dates at your conference, and then put financial aid recipients in them. To save costs, you want to pair them up, and you want to utilize the rooms maximally.

Some people think that it's a good idea to organize housing as part of your travel grants. Those people are mistaken. Housing is a terrible idea all round:

  • It doesn't scale, up or down. If you're small, you can't negotiate a worthwhile hotel block contract. If you're big, the system crashes under its /O(N²)/ weight (see below).
  • It's not good for the financial aid recipients. While there are many nice things to be said about conference hotels, they are typically not economical. When we still organized housing, many financial aid recipients opted out: they could get significantly more bang for their buck otherwise.
  • It's not good for the conference. People leave, people join, people change dates, people have preferences (or hard constraints) about who they'll stay with... Doing this for any nontrivial number of people is a logistic nightmare; doing it for trivial number of people isn't worth it.

Having humans solve the allocation problem produces inefficiencies at larger scales (i.e. humans typically come up with fairly suboptimal solutions). It's a pretty tricky problem to solve even with computers (believe me, I've tried extensively), but computers will never solve the logistic issues caused by human factors.

PyCon used to manage housing for financial aid recipients. Getting rid of this was the single best decision I've ever made for the financial aid process.

It worked out quite well for the attendees too. Providing simple tools (i.e. the equivalent of a classifieds section) is more than ample to help people find great groups to room-share with. This increased opportunities for roomsharing, because it made it much less of a hassle to mix-and-match between financial aid recipients and other attendees.

Plenty of FA people stayed in large AirBnBs or the like in groups of 6 or more, and ended up getting fantastic deals that allowed them to stay an extra few days to attend other events like sprints and tutorials.

Before the conference: from applications to allocation


Keep it simple. Use a form generator (Google Forms or Wufoo or something) for data collection. All of the processing was done with simple Python scripts, most of it in an IPython/Jupyter notebook. This enables you to create well-documented processes, which helps everyone. CSV files are your best friend.

Make as many fields on the application form as possible directly translatable to something in your allocation process. Multiple choice and boolean values are your friend; the review process will make sure the applications are accurate. Have free-form fields for documenting things, but only use them in the review process. For example, you can have a multiple choice field for Python expertise ranging from beginner to expert, and then have a free-form field for applicants' portfolios.

Names are weird. There are lots of falsehoods programmers believe about names (link). You probably want to ask for a legal name; it's quite likely that you need to keep the legal name around for your records. Ask a lawyer and/or an accountant for details. However, you probably want to ask for an (optional) preferred name as well, which you should always use when communicating with them. There's a bunch of reasons those might be different, and people may have excellent reasons for not using their legal names. For example, a legal name might give someone away as being transgender. Sometimes, you want to do that just for your /own/ convenience. People will put all sorts of stuff down as their "name", but full legal names are quite consistent. This can be useful to match up records from different sources, such as your registration database.

Speaking of gender, asking for people's gender is also tricky. Make sure you have at least a cursory understanding of how gender works before you ask. Always have a "decline to answer" button, which is distinct from "other/nonbinary". If all you really want to know is whether someone qualifies for earmarked funds, just ask the specific question you want to know; e.g. "Apply for a PyLadies grant (people who self-identify as women only, please)".

As usual in programming, state is the bane of your existence. Keep it in one place whenever possible. A (Google Drive) spreadsheet works just fine. Your scripts should operate on data extracted from them (again, CSV works fine), but not store any state. This is trickier than it sounds, but the alternative is that you'll probably end up destroying some data.


Reviews are easy to do in parallel, so get help from volunteers if needed. Establish clear guidelines for what your discrete values (e.g. Python experience) mean; not everyone agrees on what "expert" means.


I've written about allocation before.

PyCon allocates approximately 15% over budget; i.e. the budget that we allocate is 1.15x the actual grant budget. This does not include aid in the form of e.g. reduced ticket prices; remember to account for those separately!

PyCon's no-show rate is somewhere between 10% and 20%, but it's very hard to predict if the factors that contribute to that will affect your conference equally.

As mentioned in that previous blog post, you don't always want to allocate the full grant asked for. People will still be able to attend with partial grants but typically wouldn't with an empty grant. Therefore it typically makes sense to reduce everyone's grant slightly if that allows you to provide more grants.

We ended up going with a fairly simple "flood fill" algorithm. An applicant's score maps to a fraction of the budget:

$$f_i = \frac{s_i}{\sum_j s_j}$$

Where \(f_i\) is the fraction of the budget you're willing to assign to applicant \(i\), \(s_i\) is an applicant's score.

If \(f_i \ge q \cdot r_i\) (where \(q\) is the fraction of the grant you're willing to allocate and \(r_i\) is what the applicant requested, you grant them \(q \cdot r_i\); otherwise, grant them 0.

Some applicants will be below this fraction, some will be above. They could be below this fraction because they have a very high score (e.g. they are a speaker), or because they're "low hanging fruit" and not asking for very much money.

That means that if you run the algorithm again, the fractions will be bigger; the people that received allocations in the previous round were allocated less than what would've been their "fair share". Rinse, repeat until you're out of money.


Have a central website where people can see their current status and updates, both specific to the applicant and generic to the entire process. Training people to expect information there will drastically reduce the number of repetitive questions you get to answer by e-mail, which will contribute enormously to your happiness. Therefore, if people ask questions that are answered there; answer, be kind, but point out where they could have gotten that information from.

Most of the things you will have to say will be generic points about the process. Nonetheless, I have spent huge amounts of time answering individual questions about that generic process, which got get quite tedious. Hence, even a static page that doesn't show any information specific to the applicant, but just explaining the process in detail is extremely valuable.

Being up-front about how your process works is also great for prospective applicants who wouldn't feel comfortable asking. This also attracts speakers to submit talk proposals; many speakers would not propose a talk because they know they can't afford to come without financial aid. Therefore, it's important to communicate clearly if you intend to support speakers, both through your financial aid communication and your call for papers.

Once that fails, send e-mail. Once you're over a dozen or so recipients, use Mailgun. Emails particularly automated from your personal email account is a good way to get stuck in spam filters.

Disbursement (giving out money)

First off, talk to your treasurer. Possibly talk to a lawyer, too. It's quite possible, particularly if you're in the United States, that giving out a bunch of money as a non-profit comes with some fairly complex strings attached. For example, you probably have certain standards in terms of what records you have to keep.

As a European, I found it somewhat comical to still see checks in active use, but hey; it works. For many parts of the world (apparently not the United States, though) wire transfers are how you send money to people. PayPal seems to work better for larger, established organizations that use it often. There is less of a problem with the accounts or funds being frozen. It does actively restrict (or, perhaps more accurately, enforces restrictions on) sending funds to certain countries, including Brazil and India.

Cash works, but is hard to scale. With PyCon's budget of well over $100,000.00, managing cash is clearly less than ideal.

At the end of the day, be pragmatic. Do whatever your recipients can accept. Be sure to ask ahead of time, as your financial aid programs may prove to be successful in bringing people in from very different countries, with very different cultures and very different means available to them for accepting your grant. This is the case for PyCon, but I consider that a superb problem to have.


I'd like to thank the following people in no particular order:

  • Ewa Jodlowska, for managing PyCon and being the love of my life
  • Van Lindberg, for continuously inspiring me to serve
  • Diana Clarke, for Charing PyCon US in Montreal

Conflicting threat models

As I mentioned in my previous post, we have a long way to go when it comes to information security. I'll be presenting a talk on building secure systems at PyCon 2015 next month, and I hope to blog more about interesting bits of comprehensible security.

I'm a strong believer in the importance of threat models. A threat model is your idea of what you're protecting against. It may seem obvious that you can't effectively protect anything without knowing what you're protecting it from. Sadly, simply contemplating your threat model puts you ahead of the curve in today's software industry.

Threat models often simply deal with how much effort you're willing to spend to prevent something from happening. In a world with finite resources, we have to make choices. Some models are unrealistic or prohibitively expensive to defend against. These questions aren't all strictly technical: perhaps some risk is adequately covered by insurance. Perhaps you have a legal or a compliance requirement to do something, even if the result is technically inferior. These questions are also not just about how much you're going to do: different threat models can lead to mutually exclusive resolutions, each a clear security win.

Consider your smartphone. Our phones have a lot of important, private information; it makes sense to protect them. The iPhone 6 provides two options for the lock screen: a passcode and a fingerprint sensor. Passcodes have been around for about as long as smartphones have, while fingerprint sensors are new and exciting. It's clear that either of them is more secure than not protecting your phone at all. But which one is more secure?

Most people instinctively feel the fingerprint sensor is the way to go. Biometric devices feel advanced; up until recently, they only existed in Hollywood. Fingerprints have their share of issues. It's impossible to pick a new key or have separate keys for separate capabilities; you're stuck with the keys you have. A fingerprint is like a password that you involuntarily leave on everything you touch. That said, turning a fingerprint into something that will unlock your iPhone is out of reach for most attackers.

Passcodes aren't perfect either. People generally pick poor codes: important dates and years are common, but typically not kept secret in other contexts. If you know someone's birthday, there's a decent chance you can unlock their phone. At least with a passcode, you have the option of picking a good one. Even if you do, a passcode provides little protection against shoulder surfing. Most people unlock their phone dozens of times per day, and spend most of that day in the presence of other people. A lot of those people could see your passcode inconspicuously.

Two options. Neither is perfect. How do you pick one? To make an informed choice, you need to formalize your threat models.

In the United States, under the Fifth Amendment, you don't have to divulge information that might incriminate you. I am not a lawyer, and courts have provided conflicting rulings, but currently it appears that this includes computer passwords. However, a court has ruled that a fingerprint doesn't count as secret information. If you can unlock your phone with your fingerprint, they can force you to unlock it.

If your threat models include people snooping, the fingerprint sensor is superior. If your threat model includes law enforcement, the passcode is superior. So, which do you pick? It depends on your threat model.

Disclaimer: this is an illustration of how threat models can conflict. It is not operational security advice; in which case I would point out other options. It is not legal advice, which I am not at all qualified to dispense.

We're just getting started

Most conference talks are transactional. The speaker has a point to make. After the presentation, it's "over"; only spoken about in perfect tenses. You've communicated your thoughts, perhaps had a conversation or two, but, mostly, moved on.

I've given talks like these. However, about two years ago, I gave a talk that had a deep impact on my life. That talk was Crypto 101.

Right before the presentation, cryptanalytic research was released that popped RC4. I couldn't have asked for a better setup. Turns out it wasn't just luck; eventually our systemic failure as an industry in taking security seriously was bound to catch up with us. Since then, the proverbial piper has been well-paid. We've seen a plethora of serious security bugs. Huge corporations have been the victims of attacks in the billions of dollars a pop. As I'm writing this blog post, there's an article on a new TLS attack in my reading list.

It quickly became clear that this wasn't just a one-off thing. I started writing Crypto 101, the book, not too long after giving the talk. We were, unwittingly, at the crest of a wave that's still growing. Projects like PyCA and LibreSSL started fighting tirelessly to make the software we use better. Security talks became a mandatory part of the programming conference food pyramid. My friends Hynek and Ying gave fantastic talks. They, too, got "lucky" with a security bombshell: Heartbleed happened mere days before the conference.

Last week, I presented Crypto 101 again at, Rackspace's internal conference. It was well-received, and I think I provided value for people's time. One thing, more than anything, it crystallized where we are. We're not done yet. There's still a huge audience left to reach. Interest in information security has done nothing but grow. With a total of just over 100,000 downloads for the book and about half as many for the recording of the presentation, people are definitely listening. We've made real impact, and we have people's attention, but we need to keep going.

One of the two talks I'll be giving at PyCon is a more high-level overview of how we can build secure systems. More friends of mine will talk in about TLS there too. Within Rackspace, I'm focusing on information security. There are awesome things brewing here, and I hope that we can continue the great work we've been doing so far.

We've accomplished a lot, but we're just getting started.