You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Daniel L. Rall" <dl...@finemaltcoding.com> on 2005/09/23 19:08:23 UTC
Trusting server certs and --non-interactive SSL access
Assuming that I haven't already permanently trusted a SVN server accessed
over ra_dav/SSL (and haven't manipulated ~/.subversion/auth/), I see:
$ svn --non-interactive ls --password=*** https://svn.collab.net/repos/svn/
subversion/libsvn_ra_dav/util.c:826: (apr_err=175002)
svn: PROPFIND request failed on '/repos/svn/trunk'
subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
svn: PROPFIND of '/repos/svn/trunk': Server certificate verification failed: issuer is not trusted (https://svn.collab.net)
svn is apparently taking the --non-interactive as an indication that it
should fail when the cert server hasn't already been accepted as trusted.
I have a situation where I _know_ the server's cert is trusted, and the
invocation of svn is programmatic (thus the --non-interactive). Any
recommendations on avoiding the fail-fast behavior?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [proposal] Add option for trusting server certs
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Am I missing something? Why not add the self-signed cert's CA to the
>list of trusted CA's in the ~/.subversion/servers file? Then there'd
>be no prompting in the first place.
>
>
That was my first thought, too.
Generally our policy to date has been a reverberating -1 to any options
or switches that "turn off security." Since the workaround here is a
one-time action (i.e., either add the cert as Ben suggested, or connect
interactively *once* and let SVN add the trusted cert), adding such an
opiton is total overkill.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [proposal] Add option for trusting server certs
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Sat, 24 Sep 2005, Ben Collins-Sussman wrote:
> Am I missing something? Why not add the self-signed cert's CA to the
> list of trusted CA's in the ~/.subversion/servers file? Then there'd
> be no prompting in the first place.
The only option I found in the book with which to register a trusted CA is
as follows:
"Your run-time servers file also gives you the ability to make your
Subversion client automatically trust specific CAs, either globally or on
a per-host basis. Simply set the 'ssl-authority-files' variable to a
semicolon-separated list of PEM-encoded CA certificates:
[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
Many OpenSSL installations also have a pre-defined set of “default” CAs
that are nearly universally trusted. To make the Subversion client
automatically trust these standard authorities, set the
'ssl-trust-default-ca' variable to 'true'."
- http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.3.2
'ssl-authority-files' requires that I have ready access to the PEM-encoded
CA cert for every account on every machine from which I want to access the
server, and that the setup step of adding this information to the users'
~/.subversion/servers files be performed in each of those places. Given
the use case of non-interactivity, and ease of access to the CA cert, this
does not strike me as a particularly reasonable expectation from an user
experience perspective.
A callable version of 'ssl-trust-default-ca' option is what I want for
self-signed cert CAs, which appears to be the default for well-known CAs
(see libsvn_ra_dav/session.c):
/* See if the user wants us to trust "default" openssl CAs. */
trust_default_ca = svn_config_get_server_setting(
cfg, server_group,
SVN_CONFIG_OPTION_SSL_TRUST_DEFAULT_CA,
"true");
if (strcasecmp(trust_default_ca, "true") == 0)
{
ne_ssl_trust_default_ca(sess);
ne_ssl_trust_default_ca(sess2);
}
The key usability difference between 'ssl-authority-files' and
'ssl-trust-default-ca' is to make libsvn_ra_dav handle management of the CA
cert, rather than requiring N callers to do the management. Or Ben, were you
suggesting another way to implement this?
On Sat, 24 Sep 2005, Joe Orton wrote:
> On Fri, Sep 23, 2005 at 04:17:46PM -0700, Daniel L. Rall wrote:
> > Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
> > over SSL should be possible. Currently, this doesn't seem to be possible
> > for self-signed certificates.
>
> I think that all you really need here is a "--ignore-verify-failures"
> type option; a "turn off security" option for SSL.
>
> This should just be a local change to the cmdline UI which registers a
> server-cert auth provider and returns the equivalent of the "accept
> temporarily" option which the UI would present if driven interactively
> when an untrusted SSL cert is received.
Joe, were you thinking that this option would ignore more verification
failures than "untrusted CA"? I wouldn't want to tickle the completely
reasonable "turn off security -- NO!" reaction Brane mentioned.
> On 9/23/05, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
> > Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
> > over SSL should be possible. Currently, this doesn't seem to be possible
> > for self-signed certificates.
> >
> >
> > Use case:
> >
> > Code which has auth credentials available but does not run interactively
> > should be able to contact a Subversion repository over SSL using ra_dav
> > without having to jump through hoops (see "Existing work-arounds" below).
> >
> >
> > Considerations:
> >
> > This is behavior inconsistent with other Subversion options and
> > sub-commands, which all (?) provide a means to turn off interactivity
> > without impacting their basic usage.
> >
> > svn's current behavior of identifying a server certificate as "issuer not
> > trusted" is consistent with most web browsers for questionable server certs,
> > which is to prompt for acceptance when a server cert with an unknown CA
> > (e.g. self-signed). However, the fact that this behavior is absolute is
> > not conducive to programmatic execution of svn or its APIs.
> >
> > I'm guessing that the experimental svnserve-ssl branch has similar issues,
> > and would need to conform to any API modification.
> > http://svn.collab.net/repos/svn/branches/svnserve-ssl/
> >
> >
> > Existing work-arounds:
> >
> > Open a pipe to the svn binary and omit --non-interactive. This has the
> > unfortunate site effect of requiring the caller to handle _all_ possible
> > interactivity, not just the "accept certificate" prompt (for instance, an
> > auth failure will also re-prompt for auth). Especially when the caller
> > actually desires the --non-interactive behavior for the non-server cert
> > case, this is less than ideal.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [proposal] Add option for trusting server certs
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Am I missing something? Why not add the self-signed cert's CA to the
list of trusted CA's in the ~/.subversion/servers file? Then there'd
be no prompting in the first place.
On 9/23/05, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
> Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
> over SSL should be possible. Currently, this doesn't seem to be possible
> for self-signed certificates.
>
>
> Use case:
>
> Code which has auth credentials available but does not run interactively
> should be able to contact a Subversion repository over SSL using ra_dav
> without having to jump through hoops (see "Existing work-arounds" below).
>
>
> Considerations:
>
> This is behavior inconsistent with other Subversion options and
> sub-commands, which all (?) provide a means to turn off interactivity
> without impacting their basic usage.
>
> svn's current behavior of identifying a server certificate as "issuer not
> trusted" is consistent with most web browsers for questionable server certs,
> which is to prompt for acceptance when a server cert with an unknown CA
> (e.g. self-signed). However, the fact that this behavior is absolute is
> not conducive to programmatic execution of svn or its APIs.
>
> I'm guessing that the experimental svnserve-ssl branch has similar issues,
> and would need to conform to any API modification.
> http://svn.collab.net/repos/svn/branches/svnserve-ssl/
>
>
> Existing work-arounds:
>
> Open a pipe to the svn binary and omit --non-interactive. This has the
> unfortunate site effect of requiring the caller to handle _all_ possible
> interactivity, not just the "accept certificate" prompt (for instance, an
> auth failure will also re-prompt for auth). Especially when the caller
> actually desires the --non-interactive behavior for the non-server cert
> case, this is less than ideal.
>
>
> Suggested interface:
>
> Add the equivalent of a 'svn --trust-server-cert' argument to the
> libsvn_client and libsvn_ra APIs, and exposed it via the command-line
> client.
>
>
> Existing implementation:
>
> libsvn_ra_dav indirectly invokes Neon's ne_openssl.c:check_certificate()
> (passing in some callbacks), which hands back an error saying that the
> server cannot be trusted:
>
> case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
> case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
> case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
> /* TODO: and probably more result codes here... */
> failures |= NE_SSL_UNTRUSTED;
> ...
> if (failures == 0) {
> /* verified OK! */
> ret = NE_OK;
> } else {
> /* Set up the error string. */
> verify_err(sess, failures);
> ret = NE_ERROR;
> /* Allow manual override */
> if (sess->ssl_verify_fn &&
> sess->ssl_verify_fn(sess->ssl_verify_ud, failures, chain) == 0)
> ret = NE_OK;
> }
>
> Neon allows errors to be ignored via a ne_session callback:
>
> /* A callback which is used when server certificate verification is
> * needed. The reasons for verification failure are given in the
> * 'failures' parameter, which is a binary OR of one or more of the
> * above NE_SSL_* values. failures is guaranteed to be non-zero. The
> * callback must return zero to accept the certificate: a non-zero
> * return value will fail the SSL negotiation. */
> typedef int (*ne_ssl_verify_fn)(void *userdata, int failures,
> const ne_ssl_certificate *cert);
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [proposal] Add option for trusting server certs
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Fri, Sep 23, 2005 at 04:17:46PM -0700, Daniel L. Rall wrote:
> Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
> over SSL should be possible. Currently, this doesn't seem to be possible
> for self-signed certificates.
I think that all you really need here is a "--ignore-verify-failures"
type option; a "turn off security" option for SSL.
This should just be a local change to the cmdline UI which registers a
server-cert auth provider and returns the equivalent of the "accept
temporarily" option which the UI would present if driven interactively
when an untrusted SSL cert is received.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[proposal] Add option for trusting server certs
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
over SSL should be possible. Currently, this doesn't seem to be possible
for self-signed certificates.
Use case:
Code which has auth credentials available but does not run interactively
should be able to contact a Subversion repository over SSL using ra_dav
without having to jump through hoops (see "Existing work-arounds" below).
Considerations:
This is behavior inconsistent with other Subversion options and
sub-commands, which all (?) provide a means to turn off interactivity
without impacting their basic usage.
svn's current behavior of identifying a server certificate as "issuer not
trusted" is consistent with most web browsers for questionable server certs,
which is to prompt for acceptance when a server cert with an unknown CA
(e.g. self-signed). However, the fact that this behavior is absolute is
not conducive to programmatic execution of svn or its APIs.
I'm guessing that the experimental svnserve-ssl branch has similar issues,
and would need to conform to any API modification.
http://svn.collab.net/repos/svn/branches/svnserve-ssl/
Existing work-arounds:
Open a pipe to the svn binary and omit --non-interactive. This has the
unfortunate site effect of requiring the caller to handle _all_ possible
interactivity, not just the "accept certificate" prompt (for instance, an
auth failure will also re-prompt for auth). Especially when the caller
actually desires the --non-interactive behavior for the non-server cert
case, this is less than ideal.
Suggested interface:
Add the equivalent of a 'svn --trust-server-cert' argument to the
libsvn_client and libsvn_ra APIs, and exposed it via the command-line
client.
Existing implementation:
libsvn_ra_dav indirectly invokes Neon's ne_openssl.c:check_certificate()
(passing in some callbacks), which hands back an error saying that the
server cannot be trusted:
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
/* TODO: and probably more result codes here... */
failures |= NE_SSL_UNTRUSTED;
...
if (failures == 0) {
/* verified OK! */
ret = NE_OK;
} else {
/* Set up the error string. */
verify_err(sess, failures);
ret = NE_ERROR;
/* Allow manual override */
if (sess->ssl_verify_fn &&
sess->ssl_verify_fn(sess->ssl_verify_ud, failures, chain) == 0)
ret = NE_OK;
}
Neon allows errors to be ignored via a ne_session callback:
/* A callback which is used when server certificate verification is
* needed. The reasons for verification failure are given in the
* 'failures' parameter, which is a binary OR of one or more of the
* above NE_SSL_* values. failures is guaranteed to be non-zero. The
* callback must return zero to accept the certificate: a non-zero
* return value will fail the SSL negotiation. */
typedef int (*ne_ssl_verify_fn)(void *userdata, int failures,
const ne_ssl_certificate *cert);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trusting server certs and --non-interactive SSL access
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Fri, 23 Sep 2005, Mark Phippard wrote:
> "Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 09/23/2005 03:08:23 PM:
>
> > Assuming that I haven't already permanently trusted a SVN server
> accessed
> > over ra_dav/SSL (and haven't manipulated ~/.subversion/auth/), I see:
> >
> > $ svn --non-interactive ls --password=***
> https://svn.collab.net/repos/svn/
> > subversion/libsvn_ra_dav/util.c:826: (apr_err=175002)
> > svn: PROPFIND request failed on '/repos/svn/trunk'
> > subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
> > svn: PROPFIND of '/repos/svn/trunk': Server certificate verification
> failed:
> > issuer is not trusted (https://svn.collab.net)
> >
> > svn is apparently taking the --non-interactive as an indication that it
> > should fail when the cert server hasn't already been accepted as
> trusted.
> >
> > I have a situation where I _know_ the server's cert is trusted, and the
> > invocation of svn is programmatic (thus the --non-interactive). Any
> > recommendations on avoiding the fail-fast behavior?
>
> I do not know if it applies, but I recalled similar threads and found
> this.
>
> http://svn.haxx.se/dev/archive-2005-03/0046.shtml
Thanks for the pointer Mark, that is very similar to what I'm seeing. The
main difference is that I know of no --trust-server-cert flag which will
avoid a failure (along the lines of passing -m or -F as suggested in that
thread).
Surely someone else must've run into this use case before?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trusting server certs and --non-interactive SSL access
Posted by Mark Phippard <Ma...@softlanding.com>.
"Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 09/23/2005 03:08:23 PM:
> Assuming that I haven't already permanently trusted a SVN server
accessed
> over ra_dav/SSL (and haven't manipulated ~/.subversion/auth/), I see:
>
> $ svn --non-interactive ls --password=***
https://svn.collab.net/repos/svn/
> subversion/libsvn_ra_dav/util.c:826: (apr_err=175002)
> svn: PROPFIND request failed on '/repos/svn/trunk'
> subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
> svn: PROPFIND of '/repos/svn/trunk': Server certificate verification
failed:
> issuer is not trusted (https://svn.collab.net)
>
> svn is apparently taking the --non-interactive as an indication that it
> should fail when the cert server hasn't already been accepted as
trusted.
>
> I have a situation where I _know_ the server's cert is trusted, and the
> invocation of svn is programmatic (thus the --non-interactive). Any
> recommendations on avoiding the fail-fast behavior?
I do not know if it applies, but I recalled similar threads and found
this.
http://svn.haxx.se/dev/archive-2005-03/0046.shtml
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org