powered by Jive Software

Have Working Xiff3 + Crypto Solution for TLS -Enjoy : )

I have tested it multiple times against 3.4.1-3.4.4 versions of openfire. I verified packet encryption using Wireshark. I’ve tested this in both Flex and Air applications.

Things you need…

  • AS3 version of XIFF

  • replace XMPPConnection with attached version

  • replace XMPPSocketConnection with attached version

  • Latest Crypto

  • add UTF8String to util/der

  • replace DER with attached (additional type support for openfire certs)

Things to note before hand.

  • This only works with XMPPSocketConnection

  • I’m not sure but I think crypto will only work with RSA certs. I could be wrong though. Will be checking into it more later.

  • Crypto does not work with self signed certificates (detault certs generated by openfire). This can be bipassed by commenting out the checks in TLSEngine.loadCertificates(certs:Array). Just leave these two lines uncommented in the if block that checks for signed/unsigned.

trace(“TLS WARNING: No check made on the certificate’s identity.”);

_otherCertificate = firstCert;

To use TLS simply use the following boolean flag on your interface scripting that handles the initial connect. Here is my example code block.

xconn.username = usernameti.text;

userAccount = usernameti.text;

xconn.password = passwordti.text;

xconn.server = DEFAULT_SERVER;

xconn.tls = true;


Enjoy! Let me know if you have any success. Not all the kinks have been worked out but it’s a good start.
xiff-tls-fix-0.1.zip (13040 Bytes)

Wow! +100 points for you! =) Great work!

Sweeeeeeeeeeeeeeeeet. I’ve set aside some time next week to look over patches and merge stuff into trunk/provide feedback where appropriate.

Sounds good : )

I’ll help out as needed. Let me know if you have any questions or suggestions. I know a lot of people were looking for this kind of solution instead of relying on http binding. I’ve spoken with Adobe on the subject regarding the Socket class. I know several other individuals and companies have done so also. Hopefully we’ll see something from the Air/Flex team later this year once Air has been on the market longer. In the meantime this should be good enough to utilize.

Kudos to both the XIFF and Crypto team.

OK, having finally recovered from being sick last week, I’m taking a look at this now. An svn diff would have been nice for reviewing what’s different.

Did you actually get XMPPSocketConnection working? It’s been pretty finicky in my testing.

Bummer on the illness.

Yes I have it working consistently. I’m on the road

right now… in the middle of a move. I can do a comparison against the trunk (or a specific branch if you prefer) sometime next week and get back to you. I’ll probably have to grab latest and merge changes over as I’ve made some other custom tweaks to the library.


Trunk would be best. I’m trying to spend as little time in 3.5.x work as possible. Thanks

did you forget to include the file GPDataObject.as?

No GPDataObj is unrelated to the TLS.

I’ll be submitting a version comparison against trunk sometime next week when my pc arrives after the move.

In the meantime though the only things that needed to be done really was…

  1. Set a boolean for both using TLS and the handshake being successfull (so you could swap from 5222 to 5223 and change sockets).

  2. Handle proceed packet for TLS initiation.

  3. Swap sockets in xmppsocketconnection.

  4. Handle either signed or unsigned cert (see original post)

  5. Reopen stream with openfire using new socket once handshake was successfull.

  6. loop both sockets’ traffic into the same packet handler.

On Crypto’s side it didn’t have handling for all the DER types. The main one missing for the default RSA certs was UTF8String. I believe that was the only change I made to that library but I’ll post a full version of it next week as well. Also for debugging purposes I have quite a few traces I added to the TLS class files so I could see all the steps of the process taking place. I’ll include that in the version I upload next week. Should help people with debugging connections.

It should be noted that openfire gives a warning about the handshake not being handled properly. However the traffic still appears encrypted and is conducted over 5223 instead of 5222. I can post a general traffic log next week for a reference.

Ok included in this zip is…

  1. Modified Crypto package

  2. Modified XMPPConnection

  3. Modified XMPPSocketConnection

  4. TLSDemo Application

  5. SVN diff file for the connection classes. (Working copy against trunk 10307)

  6. Plane text packet capture of TLSDemo 5222 and 5223 negotiation under a single login session.

To use TLSDemo you will need to setup your own project and include Xiff and the included Crypto in your build path. Also you will need to specify your server inside the file. Let me know how things go.

xiff-tls-update-v2.zip (286249 Bytes)

see response to david for the latest version (goodies included)

i found one little bug i think. please correct me if im wrong:

line 115 of XMPPSocketConnection.as I think should be

handleReceivedData(_incompleteRawXML + s);

instead of


Line 115 is blank on the version I have.

Line 113 is the handleReceivedData(s);

If you check line 207 there’s a “_incompleteRawXML += s;” to fix the truncated xml. Although it wouldn’t hurt to add it on there. I thought the truncation only occurred on the xmlsocket and not the binary socket.

i get a truncation when i load a very large roster with the binary socket. this fixed the problem.

Cool thanks for the heads up. I’ll make the adjustment to mine as well.

OK, I’m looking over this right now. So far so good

Have you read http://www.igniterealtime.org/community/docs/DOC-1495 btw? I’d love to get this merged in if you’re ok with the contributor agreement.

i have everything working, but i have one additional question. are you serving a policy file separate from openfire’s? openfire’s policy file seems to only have 5222 included. is there a way to add 5223 without recompiling openfire? in order to serve this the policy file, i had to write a plugin that opens a socket server on a different port. am i missing something?



Glad you were able to get it working : ). I haven’t done anything special with the policy file. I’ve mainly just been working with default installs. The only customizations being plugins to handle custom IQ packets.

I know there’s an odd glitch with policy files and published flex apps in regards to the invisible history frame in the generated html file. This will sometimes disallow or block the app completely at sporadic sessions. The only way around it is to remove the include for the history. Not sure what Adobe is really doing about it. That’s only for flex apps I believe. What are you working with?

Sending the agreement over soon. You should have it later today or tomorrow at the latest.