Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

When planning for SSL for Instant Messaging, keep in mind the following:

• You can secure the Instant Messaging deployment by enabling SSL on the web container port (either Web Server or Application Server) and accessing Instant Messaging functionality by using the XMPP/HTTP Gateway (httpbind). You can also enable SSL at the mutliplexor and the Instant Messaging client can access Instant Messaging functionality directly through the mutliplexor.

• The Instant Messenger client uses only legacy SSL if it is enabled at the multiplexor. In this case, the Instant Messenger client does use startTLS of the server.

• Instant Messaging does not support end-to-end encryption using legacy SSL, so the communications between the Instant Messaging server and multiplexor is in the clear if the Instant Messaging server and multiplexor are deployed on multiple nodes and SSL is enabled at the multiplexor. If you want end-to-end encryption, you must use startTLS.

• Set the proper file and directory permissions for Instant Messaging configuration files (iim.conf and httpbind.conf in the /etc/opt/SUNWiim/default/config directory). [Instant Messaging runs as the user specified in the iim.conf file. This user needs read access to the file. If you use httpbind, the user that runs the web container should be able to access the Instant Messaging directory path and configuration file. Typically , if the deployment of Instant Messaging includes Access Manager or Portal Server, the default user is root. ] When you create additional Instant Messaging server/multiplexor instances manually, you need to also ensure that the file and directory permissions are correct. The default installation sets the file/directory permissions. The default instance directory (/var/opt/SUNWiim/default) has the following permissions:

  drwx------ 5 root other 512 Oct 16 14:24 default

• Take care when enable Instant Messaging monitoring as this exposes server statistics that could be considered security issues. The default configuration does not enable the monitoring feature. You enable this property through the iim.conf file.

• Enable debug logging only when needed, as this impacts overall system performance. Though passwords are not logged, the protocol communication between users is logged, which could be a potential security issue.

• When you enable startTLS, use a single server certificate for both client-to-server and server-to-server communication.

• The Instant Messaging server should be able to connect to Access Manager if identity integration is enabled. Similarly, Instant Messaging server needs access to the Portal Server search when deployed with Portal Server. Additionally, an Instant Messaging deployment that leverages LDAP needs proper authentication for access. Refer to each product's individual documentation to understand how to secure each component.

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

For more information, see Chapter 12, Securing Instant Messaging Using TLS and Legacy SSL, in Sun Java System Instant Messaging 7.2 Administration Guide.