hi,
ben collins-sussman suggested to have this discussion on the svn dev
list. tortoisesvn up to version 1.55 supported x509 hard tokens to
authenticate a user vs a subversion https server requestion a
certificate. but, as the usability was bad in case multiple
certificates or no certificates were present, stefan küng had to
switch it off again (it asked on every request).
steve henson, developer of the according feature in openssl, suggested
the following, with answers of stefan küng, tortoisesvn:
Stefan Küng wrote
> Dr Stephen N Henson wrote
>> Hi Guys,
>>
>> I wrote the OpenSSL CryptoAPI ENGINE. There are a few options you can use
>> relating to capieng at compile and runtime.
>>
>> If you instead do:
>>
>> perl Configure VC-WIN32 enable-capieng -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi
>>
>> the selection dialog box should not appear at all (though some CryptoAPI related
>> PIN GUIs may appear). OpenSSL will then use the first matching certificate in
>> the store.
>
>There's a problem with that:
>if that first certificate is not valid (i.e., rejected by the server),
>there is no fallback to the normal authentication. That means in such
>cases Subversion can not authenticate at all.
>
>> If you go further and do:
>>
>> perl Configure VC-WIN32 enable-capieng
>>
>> Then capieng will not be set as the default client authentication engine.
>> Without any application calls it should then not use CryptoAPI *at all*.
>>
>> Then you need something like:
>>
>> ENGINE *eng;
>> ENGINE_load_builtin_engines();
>> eng = ENGINE_by_id("capieng");
>> if (!eng)
>> {
>> /* Engine not found error */
>> }
>> if (!SSL_CTX_set_client_cert_engine(ctx, eng))
>> {
>> /* SSL client engine configure error */
>> }
>>
>> At runtime.
>>
>> If some of the above doesn't work let me know and I'll fix it.
>
>This would have to be implemented in Subversion/serf/neon. I can't
>implement this in TortoiseSVN because TSVN does not use OpenSSL directly.
>
and in a branched thread, steve wrote:
Dr Stephen N Henson wrote
> OpenSSL will only use certificates from the list of CAs supplied by the server
> but if one of those is rejected the connection will get dropped and will need to
> be reconnected with different authentication. OpenSSL can't do that
> automatically because it has no idea how to reconnect or if that is even an
> appropriate thing to do.
>
> To handle those situations needs application level support (or whatever uses
> OpenSSL directly).
>
> Continuous dialogs does sound like a session caching issue (either with the
> server or client side).
>
> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shenson_at_drh-consultancy.co.uk, PGP key: via homepage.
>
i am not sure if steve is on this list, so i copied him. i also copied
marcus who successfully used the feature.
kr, rupert.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1697051
Received on 2009-04-14 02:54:42 CEST