[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue 650, SSL certificate authority validation questions

From: <mass_at_akuma.org>
Date: 2003-01-25 02:21:03 CET

Justin Erenkrantz wrote:

 --On Friday, January 24, 2003 16:58:01 -0700 David Waite
 mass@akuma.org wrote:

 I assume all of these should be in the servers file. Other than names
 above, there are a couple of issues I'm seeking feedback on:

 I think the CA options you have listed would be system wide rather
 than per server. But, that's me.

I assume that they will be put into the servers 'default' section, which
makes them pretty much ra_dav-wide, but allows you to selectively
override options, especially when it comes to ignoring certificate problems.

 - should ssl-authorities-file have a default if not specified? If so,
 what should this be across platforms?

 Yes, I think so. ~/.subversion/certs/ sounds like a reasonable
 starting point (I believe OpenSSL supports pointing at a directory and
 adding all of the .pem's to its internal list).

 Perhaps you could do some registry entries on Win32, but I've seen
 Brane starting to mumble that Win32 should have a ~/.subversion/ dir
 anyway. I'd defer to whatever the Win32 crowd says...

I think I will just defer having a default for the time being, then.

 - should ignore-ssl-host-mismatch allow you to specify an alternate
 hostname to match against the server certificate CN?

 I don't think so. An 'alternate-ssl-host-name' per-server option
 might be sufficient rather than wrapping it in the
 ignore-ssl-host-mismatch option.

noted.

 - should there be prompting on the above errors?

 My hunch is no, but it should print out a warning at the very least.
 Perhaps the host mismatch should at least produce a prompt the first
 time (thinking of how OpenSSH does this when there is a mismatch).
 The rest of them aren't as 'fatal.' (It's out-of-date or the CA is
 unknown isn't the end of the world and probably is worth a warning if
 that.)

 From a security standpoint, they should all be 'fatal' and require
manual overriding. My install of OpenSSH client will give a failure on
host mismatch and tell the user to edit the known_hosts file with the
new cert, or to delete it at their own risk.

Eventually it might be nice to have the OpenSSH client behavior of
pulling in unknown certificates, but this may be difficult due to the
heirarchial nature of SSL certificates.

 I would also probably suggest that you do this on a branch rather than
 doing it in a cave. But, that's me. =) Earlier feedback would be
 better, I think. -- justin

I would need access to a branch to do that, but other than that its fine
:-) I will hopefully have the server certificate validation portion
workable soon, and can post a patch to the list for evaluation. For the
client certificate authentication work, I am sorta blocked on svn_auth,
and wouldn't want to create a branch while that is still rapidly evolving.

-David Waite

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:16:26 2006

This is an archived mail posted to the Subversion Dev mailing list.