[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: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 10 Mar 2015 14:33:30 +0100

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-10 14:35:47 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.