On 05.06.2013 09:11, Lieven Govaerts wrote:
>> 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.
It does some filtering, yes. But if both (or more) keys have the same
usage then this won't work.
From what I was told by companies that use such smartcards, they often
have expired certs on the card so they can still read docs signed with
them, or their signing certs also have the 'auth' flag set but it's not
used for that and they use an additional cert for authentication.
>> 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.
Yes, exactly.
I would have preferred to use the auth realm like svn does, but I
couldn't figure out how to get that information in the CAPI engine.
> Side remark: I don't see when TSVN_ClearLastUsedAuthCache() is called,
> looks like that code is unreachable.
It's used in TSVN: whenever any svn operation that TSVN executes fails
with an authentication error, that function is called to make sure that
the next attempt to authenticate won't use the cached cert index (which
could be the wrong one).
>> 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?
Yes, it still works as designed. It's completely independent of serf or
neon or even the svn library. The only thing I depend on is the error
code returned by serf if an authentication fails (I don't clear the
stored auth cert index for e.g. network errors or other errors that can
happen during an svn operation).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
Received on 2013-06-05 20:07:33 CEST