Hi,
On Tue, Jun 4, 2013 at 8:21 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> 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:
Thanks for this, interesting info. Especially because I'm adding a new
SSL implementation to serf (currently on branch multiple-ssl-impls)
using Apple's Secure Transport and Keychain Services, and I'm
encountering the same difficulties as you describe here. Although in
my case I don't have to use OpenSSL, so I can use the solutions that
Apple already provides (specifically Keychain's Identity Preference to
match client cert with hostname).
> 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.
Does OpenSSL not filter on 'Digital signature' key usage? That'd
eliminate at least the most common problems.
That part of the code may not know for which reasons the client
certificate is needed though.
> 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.
Good to know.
> 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.
So if I read your patch correctly:
- it takes the list of acceptable CA's as provided by the server
- takes the hash value of all those (not sure if it's all the CA's or
only the last one)
- use the hash value as key to store and retrieve the index of the
selected client cert in the list of available client certificates in
the Windows registry.
Side remark: I don't see when TSVN_ClearLastUsedAuthCache() is called,
looks like that code is unreachable.
> 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.
>
Right.
Did you test this with svn trunk or 1.8.0-rc? This seems completely
independent of serf or neon, so I suppose it still works as designed?
thanks,
Lieven
> 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:
> https://tortoisesvn.googlecode.com/svn/trunk/ext/build/openssl.patch
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest interface to (Sub)version control
> /_/ \_\ http://tortoisesvn.net
Received on 2013-06-05 09:12:23 CEST