subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madsen, Terry" <>
Subject RE: trust-server-cert not behaving as expected
Date Thu, 12 Mar 2015 11:09:16 GMT
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 [] 
Sent: 10 March, 2015 06:34
To: Branko ─îibej
Cc:; 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
View raw message