Home » Archived » Eclipse Communications Framework (ECF) » XMPPS connection fails on handshake(XMPPSContainer fails to connect if server requires client certificate)
 XMPPS connection fails on handshake [message #663008] |
Fri, 01 April 2011 23:52  |
 Teddy Yueh
Messages: 5
Registered: October 2010 |
Junior Member |
|
|
Hey guys,
First off, thanks for such a powerful framework! I only wish I understood it more =/, hence this post. Searches for related issues only led me to this thread:
http:// www.eclipse.org/forums/index.php?t=msg&goto=607579&S =6990684cd4f673e33f08e50762fb2387
However, I can connect if the server is not expecting a client certificate.
I have an XMPPSContainer that tries to connect to an OpenFire server which requires a client SSL certificate in order to authenticate. I believe I have the set up correct and point to my certs:
-Djavax.net.ssl.keyStore=<ks path>
-Djavax.net.ssl.keyStorePassword=<pw value>
When connecting, I get the following error:
javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 2
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnection.java:1258)
Debugging leads me to this conclusion:
1) XMPPSContainer uses the same createConnection method as XMPPContainer, which returns a org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection.
2) The connect method refers back to ClientSOContainer, which calls the connect method in ECFConnection, which uses a org.jivesoftware.smack.XMPPConnection.XMPPConnection.
3) The javadoc for the constructor it uses for XMPPConnection is as follows:
| Quote: | /**
* Creates a new XMPP conection in the same way {@link #XMPPConnection(ConnectionConfiguration,CallbackHandler)} does, but
* with no callback handler for password prompting of the keystore. This will work
* in most cases, provided the client is not required to provide a certificate to
* the server.
|
Well, poo. Walking through the code a bit, I find that this is because there is no callbackHandler to retrieve the keyStore password and the populate the keyStore. The ConnectionConfiguration doesn't look like it cares about my javax.net.ssl.keyStorePassword value, either.
So here is my question: How am I supposed to get ECF to pass my client certificate? I've looked and couldn't find any setters for relevant fields (I could be blind...).
I believe I can extend XMPPSContainer and ECFConnection so that it uses a different constructor for XMPPConnection, but is that the right way? It seems you guys have thought of a lot, so I don't want to subclass anything I shouldn't.
Thanks for your time and your thoughts,
Teddy
|
|
|
| Re: XMPPS connection fails on handshake [message #663030 is a reply to message #663008] |
Sat, 02 April 2011 13:26  |
Teddy Yueh
Messages: 5
Registered: October 2010 |
Junior Member |
|
|
So apparently, I can't extend off of ECFConnection as it is an internal class.
I tried the copy/paste code route but there seems to be too many dependencies for this to be the right approach, especially since XMPPContainer relies on ECFConnectionObjectPacketEvent in its processAsynch method.
Also, in the proceedTLSReceived method in XmppConnection, it seems like the catch-all implementation for keystores of type other than PKCS11 and Apple are handled backwards:
else {
ks = KeyStore.getInstance(configuration.getKeystoreType());
try {
pcb = new PasswordCallback("Keystore Password: ",false);
ks.load(new FileInputStream(configuration.getKeystorePath()), pcb.getPassword());
callbackHandler.handle(new Callback[]{pcb});
}
catch(Exception e) {
ks = null;
pcb = null;
}
}
In the cases of type PKCS11 and Apple, the pcb is first handled, and then the password extracted to load the keystore. The above has it backwards. Since I'm guessing this is also a 3rd party jar for ECF, there's not much that can be done there, meaning it's another piece of code to override.
It's looking more and more like I've hit a wall and the way around it is to export the org.eclipse.ecf.internal.provider.xmpp and org.eclipse.ecf.internal.provider.xmpp.smack packages, then subclass ECF and Jive classes.
Please advise so I don't have to do something so horrible  .
|
|
|
| Re: XMPPS connection fails on handshake [message #663080 is a reply to message #663008] |
Sun, 03 April 2011 10:27 |
Markus Kuppe
Messages: 177
Registered: July 2009 |
Senior Member |
|
|
On 04/02/2011 01:52 AM, Teddy Yueh wrote:
> Hey guys,
>
> First off, thanks for such a powerful framework! I only wish I
> understood it more =/, hence this post. Searches for related issues only
> led me to this thread:
>
> http://www.eclipse.org/forums/index.php?t=msg&goto=60757 9&S=6990684cd4f673e33f08e50762fb2387
>
>
> However, I can connect if the server is not expecting a client certificate.
>
> I have an XMPPSContainer that tries to connect to an OpenFire server
> which requires a client SSL certificate in order to authenticate. I
> believe I have the set up correct and point to my certs:
>
> -Djavax.net.ssl.keyStore=<ks path>
> -Djavax.net.ssl.keyStorePassword=<pw value>
>
> When connecting, I get the following error:
>
> javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 2
> at
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage (Unknown
> Source)
> at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
> at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unkno wn
> Source)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknow n
> Source)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHan dshake(Unknown
> Source)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Un known
> Source)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Un known
> Source)
> at
> org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMP PConnection.java:1258)
>
>
> Debugging leads me to this conclusion:
>
> 1) XMPPSContainer uses the same createConnection method as
> XMPPContainer, which returns a
> org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection.
>
> 2) The connect method refers back to ClientSOContainer, which calls the
> connect method in ECFConnection, which uses a
> org.jivesoftware.smack.XMPPConnection.XMPPConnection.
>
> 3) The javadoc for the constructor it uses for XMPPConnection is as
> follows:
>
> Quote:
>> /**
>> * Creates a new XMPP conection in the same way {@link
>> #XMPPConnection(ConnectionConfiguration,CallbackHandler)} does, but
>> * with no callback handler for password prompting of the
>> keystore. This will work
>> * in most cases, provided the client is not required to provide a
>> certificate to * the server.
>
>
> Well, poo. Walking through the code a bit, I find that this is because
> there is no callbackHandler to retrieve the keyStore password and the
> populate the keyStore. The ConnectionConfiguration doesn't look like it
> cares about my javax.net.ssl.keyStorePassword value, either.
>
> So here is my question: How am I supposed to get ECF to pass my client
> certificate? I've looked and couldn't find any setters for relevant
> fields (I could be blind...).
>
> I believe I can extend XMPPSContainer and ECFConnection so that it uses
> a different constructor for XMPPConnection, but is that the right way?
> It seems you guys have thought of a lot, so I don't want to subclass
> anything I shouldn't.
Hi,
I suggest you file an enhancement request [0] and maybe even come up
with a patch that adds support for a callback handler instead of
subclassing ECFConnection.
Markus
[0] https://bugs.eclipse.org
|
|
| | | |
| |
  |
Goto Forum:
Current Time: Thu Apr 25 13:24:52 GMT 2024
Powered by FUDForum. Page generated in 0.03670 seconds |
] 
Search
Help
Register
Login
Home
