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:s...@elego.de] Sent: 10 March, 2015 06:34 To: Branko Čibej Cc: users@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 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
