Locking Down a Sun Java System Instant Messaging Deployment
By Joesciallo-Oracle on Mar 12, 2007
Occasionally, someone at Sun actually reads the documents that I write. (Just kidding.) And when they do, they just might not find what they were looking for. So, like good little Sun people, they file a documentation bug. And through the miracle of modern email, that bug ends up in my inbox, alerting me to the dire crisis in the doc.
Don't get me wrong, doc bugs are a good thing, a necessary thing, it's just that I might have an opinion if it's the most important priority that I should be addressing in my Sun life, or if it can wait until some time when I'm not dealing with the usual fires.
That's what happened around the following body of information for Instant Messaging. Some group within Sun, which is tasked with ensuring that we are providing the proper security planning information on all our software products, nailed me for lack of information on Instant Messaging. Here, then, is a summary of what you'll find in the forthcoming Sun Java Communications Suite 5 Deployment Planning Guide.
Overview of Instant Messaging Security
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).
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.
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).
Providing Instant Messaging Client Access Through a Firewall
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.
Protecting the Instant Messaging Archive
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.