Thank you for the thorough answer, I appriciate it.
On Wednesday, June 09, 2010 07:03:21 pm Daniel Shahaf wrote:
> 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
> 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-10 09:29:25 CEST
This is an archived mail posted to the Subversion Users