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
Providing Instant Messaging Client Access Through
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
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