Patch for MSCAPI support, when using SVNKIt

Discussion:

Markus Oberlassnig

2010-04-23 11:29:46 UTC

Hello,

the attached patch is based on the trunk of org.tigris.subversion.subclipse.ui

The Patch supports using windows keystore (MS crypto API or MSCAPI) for getting the personal client certificate, if requested from the server. Instead of using a ".p12" file.

Description:
Since Revision 6629 of SVNKit branch 1.3.x, MS CAPI is supported for providers SunMSCAPI and keyon CAPI (for older Java Versions).
SVNKit expects either a certificate file (p12) or the String "MSCAPI" (which indicates, that the windows store should be used).
If the user knows that he has more than one matching certificates in the keystore, he can select an alias -> then SVNKit expects following string "MSCAPI;<alias>"

Here are some screenshot, to see how it works with subclipse:

[cid:***@01CAE2E6.095F0CA0]

Optional you can also select a specific certificate from your store:
[cid:***@01CAE2E6.095F0CA0]

[cid:***@01CAE2E6.095F0CA0]

Problem with Java (provider SUNMSCapi)!
There is still one problem with Java. Described in this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578658
This causes an error on the server side.
If Java is patched with the stuff from http://www.abcpages.com/~mache/sunmscapi-with-NONEwithRSA.zip then it works fine with the Java Version > 1.6.0_15
(I have not tried version 1.6.0_14, but with 1.6.0_13 it does not work)

Without the fix, following error occurs on the server error log:
[Thu Apr 08 12:58:53 2010] [info] [client 192.168.78.178] SSL library error 1 in handshake (server svsol10:444)
[Thu Apr 08 12:58:53 2010] [info] SSL Library Error: 67567722 error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
[Thu Apr 08 12:58:53 2010] [info] SSL Library Error: 67530866 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed
[Thu Apr 08 12:58:53 2010] [info] SSL Library Error: 336101498 error:1408807A:SSL routines:SSL3_GET_CERT_VERIFY:bad rsa signature
[Thu Apr 08 12:58:53 2010] [info] [client 192.168.78.178] Connection closed to child 0 with abortive shutdown (server svsol10:444)
[Thu Apr 08 12:58:53 2010] [info] [client 192.168.78.178] Connection to child 1 established (server svsol10:444)

With the fix, it works fine.

There is no problem, when using keyon CAPI!

Nice regards,
Markus

DI Markus Oberlassnig
Head of Professional Services
-------------------------------
ilogs information logistics GmbH
Krone Platz 1
9020 Klagenfurt am WÃ¶rthersee
Austria
www.ilogs.com<http://www.ilogs.com/>

T: +43 463 504 197 41
F: +43 463 504 197 55
M: +43 676 844 442 350

ilogs, the eProcess company

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2593418

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Stephen Elsemore

2010-04-28 18:46:47 UTC

Permalink

Hi Markus,

Thanks for the patch. It looks pretty good.

I did notice one problem in the Windows check. It's checking the constant Platform.OS_WIN32, which will never be null or empty, so it will always assume that the platform is windows. I would fix this by instead using the static isOsWindows method that already exists in AbstractClientAdapter.

Before committing, we'll also want to externalize the strings and replace the e.printStackTrace lines with our standard error handling.

But I've only seen the dialog by "tricking" it in debug, so I haven't really tested to see that it works. To really test, I'd need a server with certs. Do you have any advice for testing?

I assume the SVNKit check is because JavaHL does not support MSCAPI providers (do we know this for certain?)? It would be great if this feature could be extended to JavaHL.

Thanks again!

Steve

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2598253

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Markus Oberlassnig

2010-04-29 08:38:53 UTC

Permalink

Post by Stephen Elsemore
I did notice one problem in the Windows check. It's checking the constant Platform.OS_WIN32, which will never be null or empty, so it will always assume that the platform is windows. I would fix this by instead using the static isOsWindows method that already exists in AbstractClientAdapter.
Before committing, we'll also want to externalize the strings and replace the e.printStackTrace lines with our standard error handling.

OK, thank you.

Post by Stephen Elsemore
But I've only seen the dialog by "tricking" it in debug, so I haven't really tested to see that it works. To really test, I'd need a server with certs. Do you have any advice for testing?

I think you know how to configure the server.
But on client side, it is necessary to have a java version > 1.6.0_u15 and you have to patch this or you have to use JACAPI from keyon (but it is licenced).
(SVNKit needs Revision > 6600).
So if you have any problem, just contact me.

Post by Stephen Elsemore
I assume the SVNKit check is because JavaHL does not support MSCAPI providers (do we know this for certain?)? It would be great if this feature could be extended to JavaHL.

At the moment only SVNKit supports this in version 1.3.2 Revision > 6600. So, this is not yet released on the homepage.
JavaHL: Here I think, that it works a little bit different. When I'm right JavaHL uses the dll's for communication. So the dll's should be build the right way and it should work with the openssl stuff.
Is this correct?
We have also build a svn command line client with supporting MS CAPI via openssl. I think JavaHL has to be build the same way, or?

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2598743

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Stephen Elsemore

2010-04-29 17:23:16 UTC

Permalink

Hi Markus,

Thanks again. I've attached a revised patch that fixes the Windows check, as mentioned earlier, and also externalizes strings and logs errors.

But I still need to put some thought into how to handle all the dependency issues that this feature would introduce (SVNKit and Java version).

Steve

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2599031

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Markus Oberlassnig

2010-04-29 19:21:32 UTC

Permalink

Hello Stephen,

thank you for the patch. Looks good. I will test it tomorrow.

Some input for the Java version. If the security provider ist CAPI (means keyon JACAPI), than no version check for JAVA is necessary.
When the provider is SunMSCAPI, than we have still a problem here, because Java it is not working without patch. The error occures like described in my first post.
And I don't know how we can handle this.

Markus

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2599110

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Stephen Elsemore

2010-05-05 21:21:34 UTC

Permalink

It looks like SVNKit 1.3.3, published yesterday, includes support for this feature, so that is good. We could wait until we are prepared to make 1.3.3 a requirement before introducing this feature.

The Java version/patch prerequisite is more troublesome. I suppose that the best we could do is catch the error and present the user with some kind of dialog that explains what needs to be done if he wants to use this feature (upgrade Java version, apply patch, . . .)? This sounds a little messy. And, of course, we would want to make sure that someone is not confronted with such a dialog unless he has actually taken some kind of action indicating he wants to use SunMSCAPI.

Also, I wish I better understood what would need to be done to make this work with JavaHL.

Thanks.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2603687

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Markus Oberlassnig

2010-06-24 12:23:12 UTC

Permalink

There is also the possibility to check if the java used by the user is patched.

We can do the following check
Provider pjacapi = Security.getProvider("CAPI"); //$NON-NLS-1$
Provider pmscapi = Security.getProvider("SunMSCAPI"); //$NON-NLS-1$
if (pmscapi != null) {
try {
Class.forName("sun.security.mscapi.NONEwithRSASignature");
} catch (ClassNotFoundException e1) {
pmscapi = null;
}
}

The class sun.security.mscapi.NONEwithRSASignature will not be available on original java at this time until they fix it.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2625613

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Markus Oberlassnig

2010-11-30 12:55:47 UTC

Permalink

Hello Stephen,

I was not available the last 4 month.
what's the current status of this?

Nice regards,
Markus

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2686718

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Stephen Elsemore

2010-11-30 18:39:19 UTC

Permalink

I'm trying to figure out how to test this. What do I have to do to make SVN
call promptSSL in our password callback to prompt for the client
certificate? I thought that, after clearing all my cached credentials files
from the Subversion auth directories, and then trying to connect to a
forge.mil repository, I would be prompted for a certificate. But, instead,
I just connect with no prompt (a new file is created automatically in the
auth/svn.ssl.server directory). Something is cached somewhere else?

Post by Markus Oberlassnig
Hello Stephen,
I was not available the last 4 month.
what's the current status of this?
Nice regards,
Markus
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=26867
18

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2686769

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Mark Phippard

2010-11-30 18:38:26 UTC

Permalink

SVNKit has its own cache using the Eclipse keyring. So it may be
cached there if you are trying to test this patch.

You should also make sure you did not edit your ~/.subversion/servers
file to specify the path to the certificate and password in the file.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2686769

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2686771

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Stephen Elsemore

2010-12-01 17:55:40 UTC

Permalink

http://subclipse.tigris.org/issues/show_bug.cgi?id=1219

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2687054

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

Mark Phippard

2010-12-01 17:57:38 UTC

Permalink

Also note that in the latest Subclipse release (1.6.16) we now have
support for the Windows certificate store, including Smart Cards
(CAC), when JavaHL is used. However, this is only true for Win32 as
that is the only platform we provide the JavaHL binaries for.

Mark

Post by Stephen Elsemore
http://subclipse.tigris.org/issues/show_bug.cgi?id=1219
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2687054

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2687055

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].