authenticated slave-master connections

[Buildbot Friendly Helper]

This ticket is a migrated Trac ticket 521

People contributed to the original ticket: @geraldcombs (commenter), @ (watcher), m (watcher), c (watcher), . (watcher), a (watcher), @djmitche (commenter), b (watcher), e (watcher), d (watcher), g (watcher), i (watcher), h (watcher), k (watcher), - (watcher), l (watcher), o (watcher), n (watcher), s (watcher), r (watcher), u (watcher), sascha-web-buildbot.net@... (commenter), w (watcher), v (watcher), y (watcher), rutsky.vladimir@... (commenter), t (watcher)

---

Several potential buildslave admins have balked at the
idea of their machines being vulnerable to DNS/MitM
attacks, in which their buildslaves would be tricked
into connecting to a false buildmaster (either by
subverting their view of DNS so that they were directed
to the wrong IP address, or by subverting their
packets so that their connection was directed to the
wrong machine).

To address this (admittedly unlikely) vulnerability
requires that the buildslave be able to verify that it
has connected to the right buildmaster. In the longer
term, I expect to accomplish this with Foolscap/NewPB
(a secure version of PB that I have been working on for
a couple of years). In the shorter term, our options
are to run the PB-based slave-master connection over
SSL/TLS or over SSH. In either case, we must validate
the target machine's certificate/host-key against some
notion of the "right" one to get any benefit out of
this at all.

We can do the lightweight thing and mimic ssh: the
first time we connect, stash the cert/host-key in a
local file. From there on out, refuse to connect to a
machine that has a mismatched host key.

Or we can do the better form and use a secure
introduction: when the buildmaster admin gives the
master's hostname:port to the buildslave admin, include
the fingerprint of the master's certificate/hostkey as
well. This removes the vulnerability of the initial
connection being made to the malicious buildmaster.

From the point of view of the code, I think the SSL
path is easier to implement. Getting the certificate
out of the connection is a bit trickier, but I think
it's still reasonable. This will require a different
c[[(maybe c['slaveportSSL'|'slaveport']]]?), because it's
not as if we're going to use STARTTLS here. We also
need some new options for 'buildbot create-slave', to
let it know it should use PB-over-SSL instead of
regular PB. It might also add some version dependencies
on newer releases of Twisted, and will certainly
require pyopenssl on the buildslave side.

Submitted:
Brian Warner ( warner ) - 2006-10-09 07:10

---