RE: TortoiseSVN with DoD CAC (Smart Card) configuration help

Hi Stefan,
It works perfectly! I've attached the test cases I've run and they all work just fine.

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

Bob Bogardus - DMDC Contract Support
DAP Development
robert.k.bogardus.ctr_at_mail.mil
831/583-2400x4236
DSN 878-2951

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
Sent: Saturday, February 23, 2013 1:12 PM
To: Bogardus, Robert K Jr CTR DODHRA DMDC (US)
Cc: Long, Charles A CIV DODHRA DMDC (US); Calmus, Michael G CTR OSD (US); Jennings, Jared L CTR (US); Dale, Delmar; Dale, Delmar W Jr CTR DODHRA DMDC (US); users
Subject: Re: TortoiseSVN with DoD CAC (Smart Card) configuration help

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:
        

                Hi Stefan,
                [I'm taking over this issue for DMDC as Delmar is being reassigned shortly.]
                
                Thanks so much for the time you spent looking into this.
                
                Could you suggest how we should proceed? The serf issue you mentioned was last updated in Oct 2011.
                
                If it would help, I can run test nightly builds if you have time to work that approach. (I agree it's very hard to debug that way though -- unless you could print some extensive diagnostics? -- perhaps triggered with some flag setting if there's a concern about bothering other testers with the output.)
                

        Since as I mentioned before, this needs to be implemented in serf and the svn library, I can't do it directly in TSVN.
        But I'll try to implement this in serf myself, and then in the svn library and once that works in TSVN. Not sure when I have the time, maybe this weekend, but don't count on it that I get it working right away...
        

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:
http://nightlybuilds.tortoisesvn.net/CAPITest/

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

HKCU\Software\TortoiseSVN\CAPIAuthz

(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.

Stefan

-- 
       ___
  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].