Re: --trust-server-cert

Short version: --trust-server-cert bypasses ONLY the "CA is unknown"
check; it doesn't bypass hostname and expiry checks.

Arpad Ilia wrote on Wed, 9 Jun 2010 at 15:38 -0000:
> Hi!
>
> Is my observation correct that this command line switch
> (--trust-server-cert) will not accept certificates where the
> certificate hostname does not match?
>

To my surprise, yes. (I tested with
<https://svn2.sjc.collab.net/repos/svn-org>.)

Looking at the source code (from subversion/libsvn_subr/cmdline.c), we
see this documentary comment:
[[[
   Don't actually prompt. Instead, set *CRED_P to valid credentials
   iff FAILURES is empty or is exactly SVN_AUTH_SSL_UNKNOWNCA. If
   there are any other failure bits, then set *CRED_P to null (that
   is, reject the cert).
]]]

Where the possible bits are (from svn_auth.h):
[[[
/** Certificate is not yet valid. */
#define SVN_AUTH_SSL_NOTYETVALID 0x00000001

/** Certificate has expired. */
#define SVN_AUTH_SSL_EXPIRED 0x00000002

/** Certificate's CN (hostname) does not match the remote hostname. */
#define SVN_AUTH_SSL_CNMISMATCH 0x00000004

/** @brief Certificate authority is unknown (i.e. not trusted) */
#define SVN_AUTH_SSL_UNKNOWNCA 0x00000008

/** @brief Other failure. This can happen if neon has introduced a new
 * failure bit that we do not handle yet. */
#define SVN_AUTH_SSL_OTHER 0x40000000
]]]

So, yes, current --trust-server-cert doesn't bypass the hostname and
expiry checks. I can see an argument for allowing
a --I-know-what-I'm-doing-just-accept-that-cert-whatever-it-is mode,
though. (In case of an attack, the hostname and expiry are the easiest
things to get right --- the CA is the hard part --- so if we allow
bypassing *that*...)

> Thanks,
> Arpad Ilia
>
Received on 2010-06-09 19:03:15 CEST