Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » XMPPS connection fails on handshake(XMPPSContainer fails to connect if server requires client certificate)
icon5.gif  XMPPS connection fails on handshake [message #663008] Fri, 01 April 2011 23:52 Go to next message
Teddy Yueh is currently offline Teddy YuehFriend
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 Go to previous messageGo to next message
Teddy Yueh is currently offline Teddy YuehFriend
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 Embarrassed.
Re: XMPPS connection fails on handshake [message #663080 is a reply to message #663008] Sun, 03 April 2011 10:27 Go to previous messageGo to next message
Markus Kuppe is currently offline Markus KuppeFriend
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
Re: XMPPS connection fails on handshake [message #663089 is a reply to message #663080] Sun, 03 April 2011 13:51 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1023
Registered: July 2009
Senior Member
Markus Alexander Kuppe wrote on Sun, 03 April 2011 06:27
On 04/02/2011 01:52 AM, Teddy Yueh wrote:
<stuff deleted>
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


Yes, please do open an enhancement request and consider contributing a patch. This would be a nice addition to the xmpp provider.

ECF does not have corporate support, and is supported only through community contributions, so we depend upon the community to support enhancements in some manner (sponsored bug fixes/enhancements, contributions, new committers).




Re: XMPPS connection fails on handshake [message #663117 is a reply to message #663008] Sun, 03 April 2011 18:24 Go to previous messageGo to next message
Teddy Yueh is currently offline Teddy YuehFriend
Messages: 5
Registered: October 2010
Junior Member
Posted a enhancement requests here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=341724

Since the patch would have to address the smack code error as well, would a temporary solution such as subclassing XmppConnection be acceptable?

The smack ppl seem to know about this already, but I don't see any work being done: http://issues.igniterealtime.org/browse/SMACK-322

Thanks,
Teddy

[Updated on: Sun, 03 April 2011 18:25]

Report message to a moderator

Re: XMPPS connection fails on handshake [message #663119 is a reply to message #663117] Sun, 03 April 2011 18:43 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1023
Registered: July 2009
Senior Member
Teddy Yueh wrote on Sun, 03 April 2011 14:24
Posted a enhancement requests here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=341724

Since the patch would have to address the smack code error as well, would a temporary solution such as subclassing XmppConnection be acceptable?




Yes...if this would address both issues it could be done. For the first/certificate issue, my suggestion is to enhance the ECF xmpp provider to take a certificate in the IConnectContext callbacks.

Quote:


The smack ppl seem to know about this already, but I don't see any work being done: http://issues.igniterealtime.org/browse/SMACK-322

Thanks,
Teddy


I/Scott have a personal connection with Matt Tucker, Jive CTO...and could bring this up with him if it's an identifiable problem with Smack that's not being addressed. Even better would be to give them/Jive a patch with the fix for the XmppConnection issue. Feel free to connect/coordinate directly with me via the bug and/or slewis at composent.com and we'll figure out how to get this addressed.

Thanks,

Scott

Previous Topic:Eclipse CORBA Plugin problem ....
Next Topic:EDEF xml Multiple endpoint problem
Goto Forum:
  


Current Time: Mon Jun 25 04:46:15 GMT 2018

Powered by FUDForum. Page generated in 0.02358 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top