On Tue, Sep 23, 2003 at 09:56:00AM -0500, Ben Collins-Sussman wrote:
> Hold on a second... let me summarize what I see happening in the code.
>
> The subversion auth system caches credentials on disk based on a
> 'realmstring' key. The caller of the auth system defines custom
> realmstring formats for each type of credential.
>
> In the case of http 'basic' auth, ra_dav creates a realmstring based
> on the host, port, and http-realm header, something like:
>
> "<http://svn.foo.net:8080> Frank's repository"
>
> We did this, of course, to help prevent spoofing.
>
> In the case of our new server-cert handling, ra_dav is simply using
> the entire ascii-ized server-cert as a realmstring key. As Joe points
> out, this is pretty darn spoofable.
>
> But I see a simple remedy here:
>
> 1. mimic what we're doing in the http-basic-auth scenario: build a
> realmstring key based on {host, port, cert-fingerprint}.
It should be {host, port} only - the point of the cache should be to
store {host, port} -> {certificate} mappings. (or just {host, port} ->
{cert-fingerprint} mappings)
> 2. beyond that, the auth-provider which actually fetches the cache
> from disk (server_ssl_file_first_credentials()) should *compare*
> the cache contents with the incoming cert to make sure they're
> the same cert... which we're not doing!
>
> Am I making sense?
Yes, exactly. (The current code is just storing a list of trusted
certificates, so there is nothing for it to compare - it just checks
whether the certificate presented is trusted or not)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 18:07:49 2003