It’‘s probably asking too much but I’'ve got to ask;
is it possible to use an SSL connection with XIFF?
If so, how?
I’'ve been searching the docs and Flash player does not have any SSL capabilities. This means that when using XMLsocket, as does XIFF, communication is not encrypted. Other methods of communicating between Flash player and the server can be encrypted as they use the browser to encrypt the data.
I too am trying to establish a secure connection but I think it can be done.
SSL on port 5223 is deprecated and doesn’'t work with flash. TLS on port 5222 is the way to go.
I’'ve looked deeeper in the XMPP specifications (http://www.xmpp.org/specs/rfc3920.html) and tried to hack the XMPPConnection class to fit this need.
This what I came up with :
After connect you need to send this XML command in order to request TLS (SSL 3.0)
base64.encode(username*�@�host�\0�username�\0�*password)
This is where I hit the wall. Flash truncates a string at the first null character encountered. So although I have a class that encodes and decodes a string, I cannot use it the way I need.
I can send you my own version of XMPPConnection.as if you want. Maybe you can figure out something what to do next.
I’'ve also tried DIGEST-MD5 instead of PLAIN but it got really complicated.
The problem is that Flash player itself cannot use SSL encryption.
Which is why the httpd binding route seems like the only way to go.
See http://www.jivesoftware.org/community/thread.jspa?threadID=18038&tstart=0
With binding the SSL stuff is done by the browser to the binding app on the server. The binding app then communicates with Wildfire on a local connection but not encrypted, but it’‘s only locally in plain text so it’'s more acceptable.
I hate to sound like a broken record but I managed to modify XMPP connection in order to connect to wildfire 1.6 through TLS on port 5222.
I asked about this on the jabber developer mailing list and I was told that as long as I request TLS, the connection should be as secure as a https connection.
Here’'s the thread
http://mail.jabber.org/pipermail/jdev/2006-April/023520.html
Problem is that it only seems to work locally. Is that what you meant when you said flash player can’'t use SSL ?
If I try to connect to a remote wildfire server, I get slammed with a not-authorized response the minute I select the plain authentication mechanism. I’‘ve only tried it on one remote wildfire server so I’‘m not sure if it’'s my fault or theirs.
What do you think about this ?
I have managed to get it working on a remote server. I authenticate and everything’'s fine.
However, I installed a packet sniffer and I can I see the packets clear as day.
So I guess I’'m back on square one.
adi2006,
How are you making the connection to the jabber server? Is it through sockets or https binding? If, it’s the socket route, then no matter what you do, you won’‘t get an encrypted channel as flash doesn’‘t support secured sockets. I have been having some discussion with some of the guys/gals at Adobe about what it is going to take for them to implement secured sockets and basically they are telling me, that we won’'t see secured sockets in flash anytime soon, but who knows, maybe I can try some more convincing.
Are you working on a project that security is a big issue? I decided not to develop one of my chat solutions using flash because of it not supporting secured sockets.
Shoot me a email and we could discuss more.
-Dan
Hey,
Yes, I was going for the socket route and I wasn’'t aware of the flash limitation. Some posts on this forum raised some doubts and now I know for certain.
The IM client we’‘re developing isn’‘t relying entirely on flash. We have the authentication part which will be standalone application (we’'re using projectors) and ajax for the main chat functions.
I will look into https binding. This may solve more problems than one.
Adrian.
I will look into https binding. This may solve more
problems than one.
Adrian.
I’'m going down the route of httpbinding too. That way the browser handles the SSL.
I’‘ve got it working but not tested it on an SSL connection yet. I’'ll you let you know in a few days.
HTTP binding solves the problem
Just tested on an HTTPS connection and its fine. Also solves the issue of IM ports being open on corporate firewalls.
It’'s a shame that Wildfire does not provide http binding.
Nice. Congrats to you!!
What jabber server did you use it on ?
I wonder if http binding works for flash apps not embeded in browser.
MProjector is said to be featured with “seamless https integration”.
What jabber server did you use it on ?
Widfire on a client’'s server.
The httpbinding on the server is provided by JabberHTTPBind from http://zeank.in-berlin.de/jhb/
I wonder if http binding works for flash apps not
embeded in browser.
MProjector is said to be featured with "seamless
https integration".
I couldn’'t say but if XMLConnector (and presumably xml.sendAndLoad) can access HTTPS for you then it might work.
Pokoyo or adi2006,
What type of server did you install JabberHTTPBind on? I am running on Coldfusion and having a heck of a time installing JabberHTTPBind on it? Can I even install servlets on Coldfusion?
I will have to add a drop in connection class that does the http calls for my ActionScript 3.0 library, that if I can get one of these httpBind proxies installed and working.
-Dan
Yipee JM-356 HTTPBinding support is coming to Wildifire
I am clueless when it comes to servlets and .war files.
Can someone tell me how to install JabberHTTPBind on wildfire I would be very greatful.
The other option is to use AUTH-DIGEST, which is also considered secure. It’'s not really that hard – not nearly as hard as writing a TLS socket – so, I will see if I can work something out in this regard … no promises…
I’‘ve worked with AUTH-DIGEST in PHP for HTTP AUTH; I imagine it’‘s a similar (or perhaps the exact same) process of md5’'ing stuff together:
Here is how DIGEST-MD5 works from RFC 3920:
Step 3: Server informs client of available authentication mechanisms:
Step 5: Server sends a encoded challenge to client:
Step 6: Client sends a encoded response to the challenge:
The decoded response is:
username=“somenode”,realm=“somerealm”,\
nonce=“OA6MG9tEQGm2hh”,cnonce=“OA6MHXh6VqTrRk”,\
nc=00000001,qop=auth,digest-uri=“xmpp/example.com”,\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server sends another encoded challenge to client:
Step 10: Client initiates a new stream to server…[/i]
Given how straightforward it is, I am surprised XIFF does not already support it…
Looks like XIFF has support for SHA1 Digest built in but commented out of the most recent release. Check it out:
http://www.jivesoftware.org/community/thread.jspa?messageID=122488𝹸
Using SHA1 should be almost as secure as TLS for sake of authentication. Of course, it doesn’'t provide security for anything else … but there are myriad methods for encrypting and then ASCII-armoring (or base64-encoding) the of your message. So, if you have control of both clients, you can encrypt/decrypt on the fly if your concern is the message being secure.
One library for AS that currently supports Blowfish and is also LGPL is here:
Extending XIFF to handle http-binding proved not that hard at all. I don’'t have a fully working class yet but I did manage to auhenticate through it.
This is cool because now the im client will be able communicate to widlfire through https through no special handshake. Also, clients behind proxy and firewalls should be able to connect easy.
I did try to implement digest authentication but gave up at some point. I’'m not familiar with authentication protocols and for me proved to be very time consuming.
I’‘m not sure in what state your work is, but you may have problems with base64 encoding. Actioncrypt provides a wonderful class for it, but this protocol requires you to send a string with elements delimited through null characters. For flash building a string with null characters inside is impossible, since a null character will autmatically truncate the string. Anyway, I have a workaround for that. If you’'re interested give me a shout.
Thanks, SHA-1 is good enough for our purposes for now, and only required uncommenting about seven lines of code from the XIFF library. So, no need to wrestle with base64 OR the platform-dependent problems of MD5 at this point. Glad to hear you got Wildfire to work through HTTPS. Sounds like a homerun solution to use SSL at that layer.