You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2009/07/30 16:11:03 UTC
RFC: New authn/authz policy for svn.collab.net
I'm contemplating a relatively minor change of authn/authz policy for
svn.collab.net. Specifically, I'd like to make two changes:
1. Allow authenticated repository access only over SSL connections, and
anonymous repository access only over non-SSL connections. This means we
can stop using throw-away passwords for this server.
2. Unify the password files on the server into one. Some of our
repositories already only allow SSL access (because we keep more sensitive
data there), so we have a separate htpasswd file for those where folks
currently put better passwords. But maintaining those files isn't as
routine and automated as managing our regular svn commit access files, even
though there are patterns we could employ to accomplish this. But why have
patterns when you can technically guarantee the results you want?
Overall, this should greatly simplify things over the status quo, which offers:
- for one repos, anonymous read / authenticated write / no path-based authz
/ SSL or non-SSL
- for another repos, anonymous read / authenticated read+write / path-basd
authz / SSL or non-SSL
- for a third repos, authenticated read+write, SSL-only
Confused yet? Yeah.
The only downside I can think of here is that committers will require
SSL-enabled Subversion clients. While this might not be a problem for most
of us, it's not clear to me how that affects our casual users (translators,
contrib maintainers, etc.)
Thoughts?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377034
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 30, 2009 at 02:21:34PM -0400, C. Michael Pilato wrote:
> Stefan Sperling wrote:
> > 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).
>
> My goal was simplify the configuration while at least offering the kind of
> security afforded by other hosting providers. But there isn't even a
> consensus across the "big ones": GoogleCode is anonymous HTTP,
> authenticated HTTPS; SourceForge.net is HTTPS only; and Tigris.org is HTTP
> only (clearly undesirable).
>
> We can go SSL-only (with redirects for non-SSL access so old links don't
> break). It means I have to maintain my current workaround for the svn-org's
> repository (which wants to be anonymously readable minus some private bits,
> authenticatedly read/write all over)[1], but that's not the end of the world.
I guess SSL-only is fine then.
By the way, an SSL cert signed by some CA would be great.
Right now the cert is self-signed. Maybe a fresh cert could
be slipped in as a bonus while we're at it?
Otherwise, going SSL-only would mean that people would have to click
quite a lot of buttons to view our repo, at least in Firefox-3.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2379745
Re: RFC: New authn/authz policy for svn.collab.net
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Sperling wrote:
> 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).
My goal was simplify the configuration while at least offering the kind of
security afforded by other hosting providers. But there isn't even a
consensus across the "big ones": GoogleCode is anonymous HTTP,
authenticated HTTPS; SourceForge.net is HTTPS only; and Tigris.org is HTTP
only (clearly undesirable).
We can go SSL-only (with redirects for non-SSL access so old links don't
break). It means I have to maintain my current workaround for the svn-org's
repository (which wants to be anonymously readable minus some private bits,
authenticatedly read/write all over)[1], but that's not the end of the world.
[1] See http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377094
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Stefan Sperling <st...@elego.de>.
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".
Stefan
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Jeremy Whitlock <jc...@gmail.com>.
>
>> 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.
--
Jeremy Whitlock
http://www.thoughtspark.org
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377068
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Julian Foad <ju...@btopenworld.com>.
Alec Kloss wrote:
> On 2009-07-30 12:37, C. Michael Pilato 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.
Do you mean to imply that that's a discernable benefit?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377071
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Alec Kloss <al...@oracle.com>.
On 2009-07-30 12:37, C. Michael Pilato wrote:
> Arfrever Frehtes Taifersar Arahesis wrote:
[chop]
> > IMHO anonymous repository access should be still available over SSL connections.
>
> 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.
--
Alec.Kloss@oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
Re: RFC: New authn/authz policy for svn.collab.net
Posted by "C. Michael Pilato" <cm...@collab.net>.
Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-07-30 18:11:03 C. Michael Pilato napisał(a):
>> I'm contemplating a relatively minor change of authn/authz policy for
>> svn.collab.net. Specifically, I'd like to make two changes:
>>
>> 1. Allow authenticated repository access only over SSL connections, and
>> anonymous repository access only over non-SSL connections.
>
> IMHO anonymous repository access should be still available over SSL connections.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377041
Re: RFC: New authn/authz policy for svn.collab.net
Posted by Arfrever Frehtes Taifersar Arahesis <Ar...@GMail.Com>.
2009-07-30 18:11:03 C. Michael Pilato napisał(a):
> I'm contemplating a relatively minor change of authn/authz policy for
> svn.collab.net. Specifically, I'd like to make two changes:
>
> 1. Allow authenticated repository access only over SSL connections, and
> anonymous repository access only over non-SSL connections.
IMHO anonymous repository access should be still available over SSL connections.
--
Arfrever Frehtes Taifersar Arahesis
Re: WARNING: Upcoming authn/authz policy change for svn.collab.net
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Around 10pm or 11pm tonight (U.S. Eastern time), I'm going to take
> svn.collab.net offline for a bit to make these authn/authz simplifications
> I've been talking about. Here's the updated plan:
>
> * There will be a single password file for all repositories on this box.
> When merging password files, any password clashes for a given username
> will be resolved such that the password used for the most secure
> repository will win.
>
> * Non-SSL access to repositories and ViewVC will be anonymous only. No
> more authentication for non-SSL access, period.
>
> * SSL access will have the same authentication requirements as currently
> exist, with one notable exception: today we have both '/repos/svn-org'
> and '/repos/svn-org-no-anon' locations, required because of
> http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html . In
> the future, we'll still have two "locations" for this repository: one
> is "accessed via SSL, authn required" and the other is "accessed
> without SSL, authn-free, without permission to see the private portions
> of the repository." Both of these will use the URI path /repos/svn-org
> as expected.
>
This work is done now. Items of interest include:
* If you have an 'svn' repository working copy checked out without SSL and
you try to commit, you will get a MKACTIVITY error. Why? Because non-SSL
access is no longer authn-gated, so Apache sees no username, so you get no
commit. 'svn switch --relocate' is your friend.
* Here's the list of people whose 'svn' commit passwords were overwritten
with the password used for more sensitive repositories: rooneg, jrepenning,
maxb, breser.
* As an added bonus, ViewVC can now be used to view all the repositories on
the system. It's configured to honor the Subversion authz rules, anonymous
over non-SSL and authenticated over SSL.
Technically, we should probably update hacking.html and related docs to
recommend that developers check out http*S*://svn.collab.net/repos/svn/...
Finally, all these configuration changes were versioned, so if folks start
complaining, it should be pretty trivial to revert them all.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2382758
Re: WARNING: Upcoming authn/authz policy change for svn.collab.net
Posted by "C. Michael Pilato" <cm...@collab.net>.
Around 10pm or 11pm tonight (U.S. Eastern time), I'm going to take
svn.collab.net offline for a bit to make these authn/authz simplifications
I've been talking about. Here's the updated plan:
* There will be a single password file for all repositories on this box.
When merging password files, any password clashes for a given username
will be resolved such that the password used for the most secure
repository will win.
* Non-SSL access to repositories and ViewVC will be anonymous only. No
more authentication for non-SSL access, period.
* SSL access will have the same authentication requirements as currently
exist, with one notable exception: today we have both '/repos/svn-org'
and '/repos/svn-org-no-anon' locations, required because of
http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html . In
the future, we'll still have two "locations" for this repository: one
is "accessed via SSL, authn required" and the other is "accessed
without SSL, authn-free, without permission to see the private portions
of the repository." Both of these will use the URI path /repos/svn-org
as expected.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2382690
WARNING: Upcoming authn/authz policy change for svn.collab.net
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> I'm contemplating a relatively minor change of authn/authz policy for
> svn.collab.net. Specifically, I'd like to make two changes:
>
> 1. Allow authenticated repository access only over SSL connections, and
> anonymous repository access only over non-SSL connections. This means we
> can stop using throw-away passwords for this server.
>
> 2. Unify the password files on the server into one. Some of our
> repositories already only allow SSL access (because we keep more sensitive
> data there), so we have a separate htpasswd file for those where folks
> currently put better passwords. But maintaining those files isn't as
> routine and automated as managing our regular svn commit access files, even
> though there are patterns we could employ to accomplish this. But why have
> patterns when you can technically guarantee the results you want?
>
> Overall, this should greatly simplify things over the status quo, which offers:
>
> - for one repos, anonymous read / authenticated write / no path-based authz
> / SSL or non-SSL
>
> - for another repos, anonymous read / authenticated read+write / path-basd
> authz / SSL or non-SSL
>
> - for a third repos, authenticated read+write, SSL-only
>
> Confused yet? Yeah.
>
> The only downside I can think of here is that committers will require
> SSL-enabled Subversion clients. While this might not be a problem for most
> of us, it's not clear to me how that affects our casual users (translators,
> contrib maintainers, etc.)
>
> Thoughts?
By now, I really should know better than to just leave discussions of this
sort open. So I've tweaked the Subject line, and I'm amending the above to
include, "Unless I get strong objections in the next couple of days, I'll be
making this change."
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377078