Thanks for the quick reply!
I agree that this isn't an ideal solution... however, this is for an in-house server (with a strong recommendation to use https). So the risk of the sort of attack you mention is lower than if it was a random machine around the net, and TLS isn't really an option.
Would it lessen your concern if a --really-trust-server-cert would only work if the IP is a non-public one (10.x.x.x, 192.168.x.x, etc)?
Again, though, given that people are already working around this in ways that seem worse, I'm thinking that this is a matter of "paving the brown strip in the lawn".
From: Branko Čibej [mailto:brane_at_wandisco.com]
Sent: 10 March, 2015 00:46
To: users_at_subversion.apache.org
Cc: Madsen, Terry
Subject: Re: trust-server-cert not behaving as expected
On 09.03.2015 22:29, Madsen, Terry wrote:
I'm dealing with a server which has a 'non-compliant certificate', using the most recent (in the last week) Subversion Edge. Client is svn 1.8.11.
This is all command-line based...:
svn ls https://server.whate ver/svn/repository<https://server.whatever/svn/repository> --no-auth-cache --username username --password password
(with the obvious use of something real...)
Interactively, I get the prompt ".. (R)eject or accept (t)emporarily. Fine. (I also get the option to permanently accept, if I don't specify '--no-auth-cache'.)
If I add '--non-interactive', I get 'svn: E230001: ... issuer is not trusted'. Again, fine: bad cert, non interactive, gotta bail.
If I also add (append) '--trust-server-cert', based on the help for this, I expect things to work. However I still get the E230001 error.
The standard workarounds I see when Goggling seem to be:
1) (a hack) accept the cert permanently once interactively, then this should work. Means I have to do stuff on every server that might do this (and there are several). The fact that the actual behaviour is for the process to hang, rather than error out, makes chasing down all the boxes a real chore.
2) (a hack) have a stub script that does 'echo p | svn ....' (so that it's interactive and sets up the configuration). I don't like this, part of why I'm posting is problems with this workaround, buried in code written long ago by staff who are no longer with us (corporately).
3) (a hack) fiddle with the server so that it will also allow http, and where needed use the http://server.whatever instead of the https://server.whatever variant.
All of these seem to be lacking something. So, this is (another) enhancement request to put to the maintainers of Subversion: please add a '--trust-server-cert-really-i-mean-it' option so that the above workarounds aren't needed.
I am aware that 'fix the cert' is the recommended option, but this doesn't solve the problem of the moment.
To me the key is that there are already several clumsy workarounds in circulation, so a broader trust option isn't going to do anything that isn't already being done in the field, it'll just make it more straightforward --- and in the case of option 3, less intrusive. Moreover, the fact that the cert can be accepted interactively suggests that there's no good reason to not accept it in scripting mode (at least, with the "really-i-mean-it" flavour).
Option 3 seems to be the workaround answer, at least in my case, but the cure is worse than the disease in that it requires fiddling with the server and thus affects all users, not just the ones trying to get theirs scripts to work.
(Also note: this is stuff that's buried several layers deep, the direct command line is to replicate the issue).
This is also discussed at: http://svn.haxx.se/users/archive-2013-08/0494.shtml
Why do you (and apparently Stefan, too) think it's a good idea for the client to trust a cert that has expired, or has an invalid signature or does not even parse correctly? The whole point of having server certificates is to increase the chances that the client is actually talking to the correct server, not to some hacked intermediary.
Even the current --trust-server-cert is a dangerous option because you'll never actually see the information encoded in the certificate. The decision to trust a certificate should be explicit, not a side effect of some automated process that simply turns off certificate validation.
In this context, your option 1 is /not/ a hack and the only sane thing to do (assuming you actually verify the cert info that the client prints). Of course, if you don't care about security issues, then using TLS is a waste of time in the first place.
-- Brane
Received on 2015-03-10 14:01:37 CET