[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn commit: r34179 - trunk/subversion/libsvn_ra_serf

From: Bert Huijben <b.huijben_at_competence.biz>
Date: Fri, 14 Nov 2008 11:40:06 +0100

> -----Original Message-----
> From: jerenkrantz_at_tigris.org [mailto:jerenkrantz_at_tigris.org]
> Sent: donderdag 13 november 2008 21:10
> To: svn_at_subversion.tigris.org
> Subject: svn commit: r34179 - trunk/subversion/libsvn_ra_serf
>
> Author: jerenkrantz
> Date: Thu Nov 13 12:10:03 2008
> New Revision: 34179
>
> Log:
> ra_serf: Do not overwrite/munge the cert storage when OpenSSL/Serf ask
> to
> validate the entire certificate chain.

Why does serf ask to validate the entire chain?

Every other client I know tries to validate certificates with a parent/root certificate and if that fails falls back to asking whether the user trusts the leaf certificate itself.

If we would implement chain verification via the same api as the final certificate, the user would see several questions (in my case dialogs) before they can finally reach the https server. This is not common behavior.

I also think you can expect to see collisions in certificate names, as you can have several different valid versions of an intermediate certificate with the same name..
(I really wish this wouldn't be possible, as it took me a few days to find this issue on our server farm)

        Bert
>
> * subversion/libsvn_ra_serf/util.c
> (ssl_server_cert): If present, use the certificate name as the key to
> the
> storage rather than the realm string.
>
> Modified:
> trunk/subversion/libsvn_ra_serf/util.c
>
> Modified: trunk/subversion/libsvn_ra_serf/util.c
> URL:
> http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra_serf/util.c
> ?pathrev=34179&r1=34178&r2=34179
> =======================================================================
> =======
> --- trunk/subversion/libsvn_ra_serf/util.c Thu Nov 13 12:05:08 2008
> (r34178)
> +++ trunk/subversion/libsvn_ra_serf/util.c Thu Nov 13 12:10:03 2008
> (r34179)
> @@ -117,11 +117,6 @@ ssl_server_cert(void *baton, int failure
>
> apr_pool_create(&subpool, conn->session->pool);
>
> - /* Construct the realmstring, e.g. https://svn.collab.net:443 */
> - realmstring = apr_uri_unparse(subpool,
> - &conn->session->repos_url,
> - APR_URI_UNP_OMITPATHINFO);
> -
> /* Extract the info from the certificate */
> subject = serf_ssl_cert_subject(cert, subpool);
> issuer = serf_ssl_cert_issuer(cert, subpool);
> @@ -166,6 +161,24 @@ ssl_server_cert(void *baton, int failure
> SVN_AUTH_PARAM_SSL_SERVER_CERT_INFO,
> &cert_info);
>
> + /* OpenSSL/Serf will ask for validation of the entire chain (ie both
> + * server and CA). This is generally a good thing - however, we
> need to
> + * then make SVN's cert storage keyed off the certificate info so as
> + * not to stomp on the entire chain on each request.
> + *
> + * If no hostname is provided in the cert, we'll construct the
> realmstring,
> + * e.g. https://svn.collab.net:443
> + */
> + if (cert_info.hostname)
> + {
> + realmstring = cert_info.hostname;
> + }
> + else
> + {
> + realmstring = apr_uri_unparse(subpool, &conn->session-
> >repos_url,
> + APR_URI_UNP_OMITPATHINFO);
> + }
> +
> err = svn_auth_first_credentials(&creds, &state,
> SVN_AUTH_CRED_SSL_SERVER_TRUST,
> realmstring,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: svn-help_at_subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-14 11:40:27 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.