You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Madsen, Terry" <Te...@sage.com> on 2015/03/09 22:29:35 UTC
trust-server-cert not behaving as expected
I'm dealing with a server which has a 'non-compliant certificate', using the most recent (in the last week) Subversion Edge. Client is svn 1.8.11.
This is all command-line based...:
svn ls https://server.whatever/svn/repository<https://server.whatever/svn/repository> --no-auth-cache --username username --password password
(with the obvious use of something real...)
Interactively, I get the prompt ".. (R)eject or accept (t)emporarily. Fine. (I also get the option to permanently accept, if I don't specify '--no-auth-cache'.)
If I add '--non-interactive', I get 'svn: E230001: ... issuer is not trusted'. Again, fine: bad cert, non interactive, gotta bail.
If I also add (append) '--trust-server-cert', based on the help for this, I expect things to work. However I still get the E230001 error.
The standard workarounds I see when Goggling seem to be:
1) (a hack) accept the cert permanently once interactively, then this should work. Means I have to do stuff on every server that might do this (and there are several). The fact that the actual behaviour is for the process to hang, rather than error out, makes chasing down all the boxes a real chore.
2) (a hack) have a stub script that does 'echo p | svn ....' (so that it's interactive and sets up the configuration). I don't like this, part of why I'm posting is problems with this workaround, buried in code written long ago by staff who are no longer with us (corporately).
3) (a hack) fiddle with the server so that it will also allow http, and where needed use the http://server.whatever instead of the <https://variant.> https://server.whatever variant.
All of these seem to be lacking something. So, this is (another) enhancement request to put to the maintainers of Subversion: please add a '--trust-server-cert-really-i-mean-it' option so that the above workarounds aren't needed.
I am aware that 'fix the cert' is the recommended option, but this doesn't solve the problem of the moment.
To me the key is that there are already several clumsy workarounds in circulation, so a broader trust option isn't going to do anything that isn't already being done in the field, it'll just make it more straightforward --- and in the case of option 3, less intrusive. Moreover, the fact that the cert can be accepted interactively suggests that there's no good reason to not accept it in scripting mode (at least, with the "really-i-mean-it" flavour).
Option 3 seems to be the workaround answer, at least in my case, but the cure is worse than the disease in that it requires fiddling with the server and thus affects all users, not just the ones trying to get theirs scripts to work.
(Also note: this is stuff that's buried several layers deep, the direct command line is to replicate the issue).
This is also discussed at: http://svn.haxx.se/users/archive-2013-08/0494.shtml
Terry Madsen
RE: trust-server-cert not behaving as expected
Posted by "Madsen, Terry" <Te...@sage.com>.
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:stsp@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
Re: trust-server-cert not behaving as expected
Posted by Stefan Sperling <st...@elego.de>.
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
Re: trust-server-cert not behaving as expected
Posted by Branko Čibej <br...@wandisco.com>.
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).
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.
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.
-- Brane
> *From:*Branko Čibej [mailto:brane@wandisco.com]
> *Sent:* 10 March, 2015 00:46
> *To:* users@subversion.apache.org
> *Cc:* Madsen, Terry
> *Subject:* Re: trust-server-cert not behaving as expected
>
>
>
> On 09.03.2015 22:29, Madsen, Terry wrote:
>
> I'm dealing with a server which has a 'non-compliant certificate',
> using the most recent (in the last week) Subversion Edge. Client
> is svn 1.8.11.
>
> This is all command-line based...:
>
> svn ls https://server.whate ver/svn/repository
> <https://server.whatever/svn/repository> --no-auth-cache
> --username username --password password
>
> (with the obvious use of something real...)
>
> Interactively, I get the prompt ".. (R)eject or accept
> (t)emporarily. Fine. (I also get the option to permanently accept,
> if I don't specify '--no-auth-cache'.)
>
> If I add '--non-interactive', I get 'svn: E230001: ... issuer is
> not trusted'. Again, fine: bad cert, non interactive, gotta bail.
>
> If I also add (append) '--trust-server-cert', based on the help
> for this, I expect things to work. However I still get the E230001
> error.
>
> The standard workarounds I see when Goggling seem to be:
>
> 1) (a hack) accept the cert permanently once interactively, then
> this should work. Means I have to do stuff on every server that
> might do this (and there are several). The fact that the actual
> behaviour is for the process to hang, rather than error out, makes
> chasing down all the boxes a real chore.
>
> 2) (a hack) have a stub script that does 'echo p | svn ....' (so
> that it's interactive and sets up the configuration). I don't like
> this, part of why I'm posting is problems with this workaround,
> buried in code written long ago by staff who are no longer with us
> (corporately).
>
> 3) (a hack) fiddle with the server so that it will also allow
> http, and where needed use the http://server.whatever instead of
> the https://server.whatever variant.
>
> All of these seem to be lacking something. So, this is (another)
> enhancement request to put to the maintainers of Subversion:
> please add a '--trust-server-cert-really-i-mean-it' option so
> that the above workarounds aren't needed.
>
>
>
> I am aware that 'fix the cert' is the recommended option, but this
> doesn't solve the problem of the moment.
>
>
>
> To me the key is that there are already several clumsy workarounds
> in circulation, so a broader trust option isn't going to do
> anything that isn't already being done in the field, it'll just
> make it more straightforward --- and in the case of option 3, less
> intrusive. Moreover, the fact that the cert can be accepted
> interactively suggests that there's no good reason to not accept
> it in scripting mode (at least, with the "really-i-mean-it" flavour).
>
>
>
> Option 3 seems to be the workaround answer, at least in my case,
> but the cure is worse than the disease in that it requires
> fiddling with the server and thus affects all users, not just the
> ones trying to get theirs scripts to work.
>
>
>
> (Also note: this is stuff that's buried several layers deep, the
> direct command line is to replicate the issue).
>
>
>
> This is also discussed at:
> http://svn.haxx.se/users/archive-2013-08/0494.shtml
> <http://svn.haxx.se/users/archive-2013-08/0494.shtml>
>
>
> Why do you (and apparently Stefan, too) think it's a good idea for the
> client to trust a cert that has expired, or has an invalid signature
> or does not even parse correctly? The whole point of having server
> certificates is to increase the chances that the client is actually
> talking to the correct server, not to some hacked intermediary.
>
> Even the current --trust-server-cert is a dangerous option because
> you'll never actually see the information encoded in the certificate.
> The decision to trust a certificate should be explicit, not a side
> effect of some automated process that simply turns off certificate
> validation.
>
> In this context, your option 1 is /not/ a hack and the only sane thing
> to do (assuming you actually verify the cert info that the client
> prints). Of course, if you don't care about security issues, then
> using TLS is a waste of time in the first place.
>
> -- Brane
>
RE: trust-server-cert not behaving as expected
Posted by "Madsen, Terry" <Te...@sage.com>.
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".
From: Branko Čibej [mailto:brane@wandisco.com]
Sent: 10 March, 2015 00:46
To: users@subversion.apache.org
Cc: Madsen, Terry
Subject: Re: trust-server-cert not behaving as expected
On 09.03.2015 22:29, Madsen, Terry wrote:
I'm dealing with a server which has a 'non-compliant certificate', using the most recent (in the last week) Subversion Edge. Client is svn 1.8.11.
This is all command-line based...:
svn ls https://server.whate ver/svn/repository<https://server.whatever/svn/repository> --no-auth-cache --username username --password password
(with the obvious use of something real...)
Interactively, I get the prompt ".. (R)eject or accept (t)emporarily. Fine. (I also get the option to permanently accept, if I don't specify '--no-auth-cache'.)
If I add '--non-interactive', I get 'svn: E230001: ... issuer is not trusted'. Again, fine: bad cert, non interactive, gotta bail.
If I also add (append) '--trust-server-cert', based on the help for this, I expect things to work. However I still get the E230001 error.
The standard workarounds I see when Goggling seem to be:
1) (a hack) accept the cert permanently once interactively, then this should work. Means I have to do stuff on every server that might do this (and there are several). The fact that the actual behaviour is for the process to hang, rather than error out, makes chasing down all the boxes a real chore.
2) (a hack) have a stub script that does 'echo p | svn ....' (so that it's interactive and sets up the configuration). I don't like this, part of why I'm posting is problems with this workaround, buried in code written long ago by staff who are no longer with us (corporately).
3) (a hack) fiddle with the server so that it will also allow http, and where needed use the http://server.whatever instead of the https://server.whatever variant.
All of these seem to be lacking something. So, this is (another) enhancement request to put to the maintainers of Subversion: please add a '--trust-server-cert-really-i-mean-it' option so that the above workarounds aren't needed.
I am aware that 'fix the cert' is the recommended option, but this doesn't solve the problem of the moment.
To me the key is that there are already several clumsy workarounds in circulation, so a broader trust option isn't going to do anything that isn't already being done in the field, it'll just make it more straightforward --- and in the case of option 3, less intrusive. Moreover, the fact that the cert can be accepted interactively suggests that there's no good reason to not accept it in scripting mode (at least, with the "really-i-mean-it" flavour).
Option 3 seems to be the workaround answer, at least in my case, but the cure is worse than the disease in that it requires fiddling with the server and thus affects all users, not just the ones trying to get theirs scripts to work.
(Also note: this is stuff that's buried several layers deep, the direct command line is to replicate the issue).
This is also discussed at: http://svn.haxx.se/users/archive-2013-08/0494.shtml
Why do you (and apparently Stefan, too) think it's a good idea for the client to trust a cert that has expired, or has an invalid signature or does not even parse correctly? The whole point of having server certificates is to increase the chances that the client is actually talking to the correct server, not to some hacked intermediary.
Even the current --trust-server-cert is a dangerous option because you'll never actually see the information encoded in the certificate. The decision to trust a certificate should be explicit, not a side effect of some automated process that simply turns off certificate validation.
In this context, your option 1 is /not/ a hack and the only sane thing to do (assuming you actually verify the cert info that the client prints). Of course, if you don't care about security issues, then using TLS is a waste of time in the first place.
-- Brane
Re: trust-server-cert not behaving as expected
Posted by Branko Čibej <br...@wandisco.com>.
On 09.03.2015 22:29, Madsen, Terry wrote:
>
> I'm dealing with a server which has a 'non-compliant certificate',
> using the most recent (in the last week) Subversion Edge. Client is
> svn 1.8.11.
>
> This is all command-line based...:
>
> svn ls https://server.whate ver/svn/repository
> <https://server.whatever/svn/repository> --no-auth-cache --username
> username --password password
>
> (with the obvious use of something real...)
>
> Interactively, I get the prompt ".. (R)eject or accept (t)emporarily.
> Fine. (I also get the option to permanently accept, if I don't specify
> '--no-auth-cache'.)
>
> If I add '--non-interactive', I get 'svn: E230001: ... issuer is not
> trusted'. Again, fine: bad cert, non interactive, gotta bail.
>
> If I also add (append) '--trust-server-cert', based on the help for
> this, I expect things to work. However I still get the E230001 error.
>
> The standard workarounds I see when Goggling seem to be:
>
> 1) (a hack) accept the cert permanently once interactively, then this
> should work. Means I have to do stuff on every server that might do
> this (and there are several). The fact that the actual behaviour is
> for the process to hang, rather than error out, makes chasing down all
> the boxes a real chore.
>
> 2) (a hack) have a stub script that does 'echo p | svn ....' (so that
> it's interactive and sets up the configuration). I don't like this,
> part of why I'm posting is problems with this workaround, buried in
> code written long ago by staff who are no longer with us (corporately).
>
> 3) (a hack) fiddle with the server so that it will also allow http,
> and where needed use the http://server.whatever instead of the
> https://server.whatever variant.
>
> All of these seem to be lacking something. So, this is (another)
> enhancement request to put to the maintainers of Subversion: please
> add a '--trust-server-cert-really-i-mean-it' option so that the above
> workarounds aren't needed.
>
>
>
> I am aware that 'fix the cert' is the recommended option, but this
> doesn't solve the problem of the moment.
>
>
>
> To me the key is that there are already several clumsy workarounds in
> circulation, so a broader trust option isn't going to do anything that
> isn't already being done in the field, it'll just make it more
> straightforward --- and in the case of option 3, less intrusive.
> Moreover, the fact that the cert can be accepted interactively
> suggests that there's no good reason to not accept it in scripting
> mode (at least, with the "really-i-mean-it" flavour).
>
>
>
> Option 3 seems to be the workaround answer, at least in my case, but
> the cure is worse than the disease in that it requires fiddling with
> the server and thus affects all users, not just the ones trying to get
> theirs scripts to work.
>
>
>
> (Also note: this is stuff that's buried several layers deep, the
> direct command line is to replicate the issue).
>
>
>
> This is also discussed at:
> http://svn.haxx.se/users/archive-2013-08/0494.shtml
>
Why do you (and apparently Stefan, too) think it's a good idea for the
client to trust a cert that has expired, or has an invalid signature or
does not even parse correctly? The whole point of having server
certificates is to increase the chances that the client is actually
talking to the correct server, not to some hacked intermediary.
Even the current --trust-server-cert is a dangerous option because
you'll never actually see the information encoded in the certificate.
The decision to trust a certificate should be explicit, not a side
effect of some automated process that simply turns off certificate
validation.
In this context, your option 1 is /not/ a hack and the only sane thing
to do (assuming you actually verify the cert info that the client
prints). Of course, if you don't care about security issues, then using
TLS is a waste of time in the first place.
-- Brane