On 10.03.2015 13:59, Madsen, Terry wrote:
>
> 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".
>
For an internal server, there's really no good excuse for having an
invalid certificate. I can't guess what exactly is invalid about it; one
quite likely reason is that it has expired (if it were a valid
self-signed cert for the server, for example, --trust-server-cert would
be enough).
As to your other argument about there being workarounds: there are
always workarounds. For example, you could run a small socket adapter
(based on, e.g., Curl or OpenSSL's s_client) that could completely
ignore the server certificate and present a plain HTTP connection to
your SVN client.
IMO, it's better for users to use any kind of workaround than for
Subversion to devalue TLS connections by having an option to completely
ignore server certificate validity.
-- Brane
> *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
> <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:09:04 CET