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
