Instant Messaging supports the following levels of security:
No Security. Communication is all plain text from client through the multiplexor to the server.
Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).
startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.
The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).
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).
The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.
When planning to use the XMPP/HTTP Gateway, keep in mind the following:
Use port 5222 at the Gateway if the Gateway is communicating to the server through a multiplexor. Also, use port server port 5269 if no multiplexor is involved. You can specify port 5222 or 5269 in the httpbind.conf file.
The XMPP/HTTP gateway supports both startTLS and legacy SSL. If you want legacy SSL support, enable SSL on the Web Server port. However, if the XMPP/HTTP gateway configuration points to the multiplexor instead of the server, disable legacy SSL at the multiplexor. Additionally, if you want startTLS support, enable startTLS on the server and all communications will be encrypted.
Do not expose the Instant Messaging server to direct access. In a typical deployment scenario you would locate the multiplexor in the DMZ, and open the multiplexor to server communication port (45222 usually) in the second firewall.
Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.