RE: TortoiseSVN with DoD CAC (Smart Card) configuration help
From: Bogardus, Robert K Jr CTR DODHRA DMDC (US) <robert.k.bogardus.ctr_at_mail.mil>
Date: Mon, 25 Feb 2013 21:39:50 +0000
Our repositories are readable by everyone, just some are write-restricted - this version works fine with that.
A function to remove the cached index for the last connection is a great solution - we'll need that for sure.
Let me know if you need any other testing and when you've committed a version we can use.
We really appreciate your help and your quick response.
Thanks so much!
Bob Bogardus - DMDC Contract Support
On Wed, Feb 20, 2013 at 10:22 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
On 19.02.2013 21:51, Bogardus, Robert K Jr CTR DODHRA DMDC (US) wrote:
Since as I mentioned before, this needs to be implemented in serf and the svn library, I can't do it directly in TSVN.
So, implementing this in serf and/or svn doesn't work either:
Since smartcard certificates and certificates in the cert store are usually marked as "not exportable", there is no way to get them out of the smartcard or the cert store. You can only use them with the windows crypto API, but never ever get their key directly.
Which means to actually use those certificates, de/encrypting data has to be done with the crypto API.
OpenSSL however does not provide callbacks for clients to do that. Only 'engines' (kind of plugins) can do that, and that's what the e_capi engine in OpenSSL actually does.
So: clients can not use those certificates.
No way around that, no tweaks or hacks possible.
It seems the only way to get this really working is to use the e_capi engine in OpenSSL and patch that engine to work better in our situation.
As I mentioned before, the way e_capi works right now is not really usable. A short recap:
If a server requests a certificate, it first checks all available certificates and selects those that match the request.
* if there's only one certificate that matches the request, that certificate is used unconditionally. That's what you see if there's only one certificate on your smartcard, and as you mentioned this works quite well.
(since for some people even this doesn't work, TSVN has patched e_capi to disable the engine completely with a registry entry)
* if there are more than one certificate available that match the request, e_capi would show a dialog to select the certificate. But that selection is not stored/saved/cached. That means for longer checkouts/updates/... you'll get more than one dialog to choose the very same certificate. And the repository browser which makes a separate connection for every listed folder would be completely unusable - you'd get hundreds of those dialogs before you could even see the first file/folder listing.
right now, TSVN has patched e_capi to never show the cert selection dialog, but show its own instead. TSVN caches the selection so you won't get the dialog more than once. Problem is: that only works if the certificate is exportable - as you've seen with your smartcards that have more than one matching cert.
It seems the only way to make this work better is to patch the e_capi engine even more (a perfect solution might not be possible, at least I haven't found one yet):
We have to patch e_capi to save the user choice of the certificate.
Here's how I've implemented this:
* the index of the certificate in the store is saved to the registry
* if another request from the same cert chains is requested, use the saved index and return that certificate without showing the selection dialog
* export a function to remove the cached index for the last connection
This should work fine in most situations.
But: in some situations, this requires user interaction or won't work at all.
* if the order of the certificates in the store/smartcard changes or the user selected the wrong certificate, the connection will fail. And further connections will fail as well. If the server returns an auth error code, then TSVN will automatically clear the cached data from the registry, and the next attempt will show the cert selection dialog again. However if the server does return another error code indicating a connection failure instead, TSVN will not recognize this and not clear the cached cert index. So further connections will fail over and over again. The user must then remove that cached data manually with the registry editor (for now) or in the settings dialog (will do that later).
* if there are multiple repositories the user connects to that have the same certificate requests, but the user must use different certificates for those (e.g., if the user has two certificates, one as 'user' and one as 'admin') then e_capi will repeatedly fail and operations need to be repeated a lot. And depending on the error code, the use would also have to clear the auth data every time.
* worst case scenario: situation as in the previous point, but now with those two repositories connected with svn:externals, and the user is using the repository browser. Here, best thing would be to just disable e_capi completely since you won't get the repo browser to show up properly.
If you've read all my nonsense above: I have a test version for you to try:
Please note that this version is from TSVN trunk, using trunk of the svn library. If you were using TSVN 1.7.x before, you have to upgrade your working copies first (or use the repo browser only).
Do you have a repository where you don't have access to certain subfolders? If yes, please use the repo browser and try to browse to those folders. It would be interesting to see how the patched e_capi reacts in this situation.
If not, please test at least the following:
* run update on a working copy
* show the log
* show the repo browser
always check how many times you have to select the certificate.
And: please also test what happens if you select the wrong certificates of the two you have on your smartcard (I'm guessing only one is valid or can be used to access the repository).
If you need to clear the cached cert selection, use regedit.exe to delete the registry key
(you could also change the value of the entry below that key to another value and see what happens then).
I hope it's not too much work for you to test this, but I really need someone with such a setup to test this before I commit my changes.
-- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/> The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net ------------------------------------------------------ http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3049805 To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
This is an archived mail posted to the TortoiseSVN Users mailing list.