Testing encryption

Hello,

Wildfire marks my company’'s first forray into instant messaging, Java and Open Source products, so bear with me if this is really dumb posting.

We selected Wildfire as a candidate for our internal IM in large part because the product encrypts the IM traffic. We work with HIPAA information and need to make sure all communication is secure. We’'re testing Wildfire with Gaim, Spark and Exodus.

When logging in via Exodus, we get a pop-up related to the SSL certificate being server up by Wildfire (we’‘re using the default cert, not one of our own yet.) The other clients don’'t show any signs of a certificate.

My core question is, how do I know that the messages are actually encrypted? Is there a way to “prove” the security of the messages to an external auditor in the event we’'re faced with a security audit??

Thanks for any insights you can share.

Hi,

you may want to read the SSL guide http://www.jivesoftware.org/builds/wildfire/docs/latest/documentation/ssl-guide. html and change the certificates if you want to get rid of the message Exodus displays. I assume that the other clients do not care about the SSL certificates.

You should require encryption in the web console on page http://localhost:9090/ssl-settings.jsp to make sure that all client connections are encrypted.

It seems that for server-2-server connections such a setting is missing! Disable s-2-s as long as this is not possible or maybe someone knows where this can be configured.

You may want to use a network sniffer like Ethereal to analyze the traffic and check whether it is encrypted or not if you want to verify that the server works as expected.

Clients usually display a closed lock somewhere it the connection is encrypted.

LG

Hey LG,

I’'m not sure which feature is missing in that page. The “Security Settings” page (ssl-settings.jsp) includes 2 sections: 1) Client Connection Security and 2) Server Connection Security. By default, Wildfire will try to use a secured channel for server-to-server communication but if the remote server does not support it (which is quite possible) it will fall back to the server-dialback method that uses plain sockets.

Regards,

– Gato

Sorry Gato,

I have no idea why I missed the Server Connection Security section. Of course it’'s there, also on my installation (;

LG