Thank you for the thorough answer, I appriciate it. Arpad Ilia
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 > <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
signature.asc
Description: This is a digitally signed message part.
