On Thu, Jul 30, 2009 at 11:41:34AM -0600, Jeremy Whitlock wrote:
> >> I disagree. Doing this adds unnecessary complication to the configuration
> >> (some of which is exactly the kind of thing I'm trying to get rid of by
> >> applying the rules I suggested), unnecessary performance/load penalties to
> >> the server (why do we want to be doing SSL calculations for anonymous
> >> accessors?), and all while bringing no discernible benefit to the users.
> > SSL for anonymous access prevents MITM attacks on downloads from the
> > repository.
> Subversion's source code isn't something that is hidden so why is a MITM
> scenario a concern? If a MITM scenario does occur, SSL or not, there is
> a bigger problem that Subversion's server configuration can't help with.
This has nothing to do with Subversion being an open source project.
The point is that someone could set up a rouge svn.collab.net server,
direct people to the rouge server (e.g. via DNS poisoning) and have an
unsuspecting victim download maliciously modified Subversion source code
which the victim will then compile, install, and run on their system.
It's also theoretically possible to inject code into the Subversion
sources being downloaded from the real svn.collab.net server.
Granted, this is fairly hard, since we're talking about a compressed
delta stream and not plaintext, but it's theoretically possible.
In security, you want to be sure that an attack is *impossible* in
practice before you can really say you are secure. SSL is known
to be impossible to break in practice if handled correctly.
In my opinion, if we can keep the SSL option for anonymous users
without major effort, let's keep it. It's the only way for anonymous
users to get our at trunk code securely (releases are already PGP-signed).
While talking about SSL, we might also want to publish the fingerprints
of the server somewhere where they are easy to get at. I'm not sure if they
are currently available somewhere. I use SSL myself but I use a
trust-on-first use model of fingerprint "verification".
Received on 2009-07-30 20:03:41 CEST