Proving port 5222/5223 is encrypted

I am sure that I tested this when I was setting up Openfire using Wireshark. I could see that the xmpp packets were encrypted when I set Spark to use port 5222/3 and forced security to ‘required’ in the openfire web interface, I could also set it to see clear text and knew that it was unencrypted.

I am back to testing it again (after getting secure audio/video working) and am finding that all I can see in Wireshark now, using xmpp is:

[truncated] \027\003\001\000\321\377\331?\346\304\031d\027\026\265\200\377\355\302=*\254@^\ 322\272z\022>\207\023\227BD\3617~y\

I can’t find anything on the meaning of this in the wireshark forums and cannot prove that it is encrypted even though it is not in cleartext. I have no idea what [truncated] means.

Can I get confirmation that the following table is correct for the ‘Security settings’ setting in the Openfire web interface and Spark using each available port:

**Port / Security setting
**
Optional
Required
5222
Not secure
Secure
5223
Secure
Secure

If anyone happens to know the meaning of [truncated] I would love to know.

I have tried this on Windows Vista, Windows XP and Linux using Wireshark over both wireless and LAN and get the same [truncated] reading every time.

I am using Openfire 3.6.0a.

You have a few options. First, you can trust that it is, because so many people say that it is (developers included). Your other option is to verify it yourself. This can be done in a few different ways:

Option A: SSL/TLS is a published protocol, and there are tools that will look at an SSL/TLS stream and give you information about it. If you happen to know the private keys (that live only on the server) you can even decrypt the traffic, but otherwise it only tells you some basic info. ssldump is one such tool. I think ethereal/wireshark can do this as well.

Option B: Look at the source. This means understanding the java language, and inspecting the code to make sure it is doing what you want it to do. You might also want to look at the source code to Java itself, then, to make sure it is doing what you expect, if you feel especially paranoid.

Oh, and I think the [truncated] message is because the pcap snaplen is smaller than the full packet, and thus what you see is not the full packet. There are options to set that.

Thanks for the reply. Yep, I am the paranoid sort and like to prove things to myself.

I had a look at ssldump and can see that a certificate and handshake is being sent when I connect using Spark. It looks like the certificate gets sent whether or not I am ‘requiring’ a secured connection though (using port 5222), does Openfire always use a secure mode if it is available (maybe when there is a certificate installed)?

I also had a go at setting the Wireshark ‘limit each packet to xx bytes’ in the Options. Is that the one you think sets the pcap snaplen? I have never heard that term before. If so, it made no difference when I set it to 10000 bytes.

As long as encryption is offered, Spark is going to try and use it (unless youve told spark not to). Spark (at present) does not check the validity of the cert fully, so it only prevents 3rd party snooping, it wont help you in the event someone compromises DNS or your server. But its better than nothing. Hopefully ssldump has satisfied your paranoia :slight_smile:

Yes, the “limit packet to xx bytes” is going to be the snaplen (the tcpdump name of the option). If setting that above the MTU didnt change things, then I have no idea what the truncated thing means. You might try tcpdump itself, or the windows equivalent (I think its called WinDump or something).

Yes, SSLDump has given me enough information to make me happy. Using that program I can also see the ‘ClientKeyExchange’ so thanks for pointing me in that direction, I would not have found it otherwise.