subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan K√ľng <>
Subject Re: Should missing smart card support not be added in the release notes?
Date Tue, 04 Jun 2013 18:21:44 GMT
On 04.06.2013 13:56, Lieven Govaerts wrote:

> You are referring to a configuration where OpenSSL uses MS's CryptoAPI
> to use the Windows certificate store. Never used it myself, but I see
> that TSVN has implemented this, with an extra dialog to select a
> client certificate if multiple were found.
> I see no reason why that won't work with serf, we probably would have
> heard about it if not.
> So for Windows there's no problem, only for Mac & Linux we don't have
> a smart card solution in 1.8.0 at this time.

Some information about this:

First, you have to compile OpenSSL with CAPI enabled. The default build 
does not use this.
There are two build flags for the CAPI engine in OpenSSL. The first one 
simply activates the engine, but it only works if the smartcard has only 
one certificate that matches the request from the server. If there are 
more than one matching cert on the card, then this won't work at all. 
This actually happens a lot: expired certs that are still on the card, 
or people having one cert for authentication and one for signing 
documents - both of them matching the request info from the server.

A second build flag enables an UI: the CAPI engine shows a cert 
selection dialog in case that there are more than one matching cert so 
the user has to select the right one.

This works fine. But (and here's the big 'but'): there's no way to store 
the selection. So for every session that cert selection dialog is shown. 
And of course for longer sessions like a checkout, that dialog is shown 
several times because there's also a timeout on how long such a cert is 
valid and has to be re-read from the card (so you can pull the card out 
of the card reader to stop the session).

So for automated checkouts or most operations with an svn client 
(especially TSVN that uses multiple sessions for most commands), the 
user has to select the certificate multiple times. That get's annoying 
immediately and makes it practically unusable.

In TSVN 1.7 I implemented my own cert handling by reading out the 
certificate from the cert store and passing that back to svn as the 
pcks12 file. That way I could store the user selection and only have the 
user ask once for the certificate.
Problem with this is that the certificate must be imported into the cert 
store as "exportable". If it's not exportable, I can't get the cert and 
pass it to svn as the pcks12 file.

So to get rid of these problems I had to patch the CAPI engine in 
OpenSSL: I have to store the certificate the user selects in the dialog 
in that CAPI engine, because only there can such certs be used without 
having to export them: the CAPI engine uses the CryptoAPIs to only *use* 
the certificates but never actually *see* them.

However, if the user selection is stored in the CAPI engine and the user 
chose the wrong certificate, authentication will fail and keep failing: 
there's no 'retry' in case the authentication fails and so no chance to 
have the user select another cert. That's why I also had to export a 
custom function from that CAPI engine in OpenSSL to clear the user 
selection in case the authentication fails.
Since there are no retries for auth failures in this situation, if the 
user makes the wrong choice the operation fails immediately and the user 
has to restart the operation. But with my patched CAPI engine at least 
the user selection can be stored and cleared if necessary.

This patched version of the CAPI engine in OpenSSL is already in use in 
a company and works fine there.

In case you're interested: the patch for e_capi.c in OpenSSL is here:


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\

View raw message