subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: trust-server-cert not behaving as expected
Date Tue, 10 Mar 2015 13:33:30 GMT
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
                             certificates
  --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

Mime
View raw message