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

RE: trust-server-cert not behaving as expected

From: Madsen, Terry <Terry.Madsen_at_sage.com>
Date: Thu, 12 Mar 2015 11:09:16 +0000

This looks like it covers all the bases. Also (using grep) it looks to provide auditability / discoverability in the case of "inherited" systems. Thank you, and looking forward to 1.9!

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: 10 March, 2015 06:34
To: Branko ─îibej
Cc: users_at_subversion.apache.org; Madsen, Terry
Subject: Re: trust-server-cert not behaving as expected

On Tue, Mar 10, 2015 at 02:07:45PM +0100, Branko ─îibej wrote:
> 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).

Agreed. Please get your certificate fixed.
Why even use SSL/TLS if nobody is taking care of certs?

> 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.

This is beyond the skill and time budget of many of our users, I'm afraid.
Especially those using non-UNIX-based systems.

> 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.

FWIW 1.9 will ship with the following new options. They selectively allow users to bypass specific certificate validation failures.
But only with --non-interactive, i.e. this is mostly intended for automated jobs which might have to be fixed up very quickly even in case a cert has gone bad.

  --trust-server-cert : deprecated; same as --trust-unknown-ca
  --trust-unknown-ca : with --non-interactive, accept SSL server
                             certificates from unknown certificate authorities
  --trust-cn-mismatch : with --non-interactive, accept SSL server
                             certificates even if the server hostname does not
                             match the certificate's common name attribute
  --trust-expired : with --non-interactive, accept expired SSL server
  --trust-not-yet-valid : with --non-interactive, accept SSL server
                             certificates from the future
  --trust-other-failure : with --non-interactive, accept SSL server
                             certificates with failures other than the above
Received on 2015-03-12 12:09:46 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.