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

Re: Hard time to verify ssl server certificate.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-02-23 18:27:13 CET

[keeping this on the users@ list]

On Feb 23, 2005, at 11:07 AM, Josef Wolf wrote:

> On Tue, Feb 22, 2005 at 09:03:03PM -0600, Ben Collins-Sussman wrote:
>> On Feb 17, 2005, at 3:42 PM, Josef Wolf wrote:
>>> But when I connect to the same sever with svn, and svn asks me to
>>> verify the certificate, it prints me a completely _different_
>>> fingerprint.
>> Hm, I can't reproduce this using the latest svn code. (And the ssl
>> code hasn't been touched in ages.)
>> For example, when I tell mozilla to look at
>> https://svn.red-bean.com/repos/sussman
>> It shows me 2 different fingerprints: one for SHA1, one for MD5.
> Ah, this seems to be the problem here: subversion prints the sha1
> digest
> while tinyca, konqueror and even openssl print only md5 digest.
> The openssl command line tools default to md5. The only exception is
> keys, where _always_ sha1 is used. Since I generated a RSA key,
> openssl,
> tinyca and konqueror present md5 signatures to me.
> I am not a crypto expert, but I wonder whether it would make sense to
> adopt openssl's behavior to subversion? Maybe it would make even more
> sense to simply print both digests so the user can choose the one that
> he was given when the certificate was generated. IMHO, the current
> behavior can cause lot of confusion to people that are not
> crypto-experts.

Subversion is using the API provided by neon, which is just a wrapper
around openssl functionality. Take a look in libsvn_ra_dav/session.c:

   /* Extract the info from the certificate */
   cert_info.hostname = ne_ssl_cert_identity(cert);
   if (ne_ssl_cert_digest(cert, fingerprint) != 0)
       strcpy(fingerprint, "<unknown>");
   cert_info.fingerprint = fingerprint;
   ne_ssl_cert_validity(cert, valid_from, valid_until);
   cert_info.valid_from = valid_from;
   cert_info.valid_until = valid_until;
   cert_info.issuer_dname = issuer_dname;
   cert_info.ascii_cert = ascii_cert;

Maybe we should be doing more? Or maybe there's some other neon cert
APIs we should be using? Patches are welcome.

> In addition, it forces one to take extra steps to verify the
> certificate.
> Unfortunately, the certificate is stored in a format that is not
> understood by openssl.

It's generated by the call to

   char *ascii_cert = ne_ssl_cert_export(cert);

This ain't my field of expertise. Perhaps you should take up this
conversation on the neon list.

> So I ended up with
> $ grep ~/.subversion/auth/svn.ssl.server/07* | \
> perl -ne 'print "-----BEGIN CERTIFICATE-----\n";
> $x=64;
> while ($x<length $_) {
> substr($_,$x, 0, "\n");
> $x+=65;
> }
> print "$_-----END CERTIFICATE-----\n";' | \
> openssl x509 -inform PEM -fingerprint | \
> grep Fingerprint
> to verify the certificate. IMHO, verifying a certificate should not
> be _that_ hard ;-)
> BTW: It would be fine to have an independent option to store ssl
> certificates. To have a ssl certificate stored, I need to
> enable store-auth-creds (at least temporarily) and end up
> with my password in cleartext in the ~/.subversion/auth/svn.simple
> directory :-( :-( :-(

That's why we have the new "store-passwords = no" option in the
run-time config file. That way passwords will not be stored, but certs

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 23 18:29:40 2005

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

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