[JDEV] Security in XMPP/Jabber: some questions
mass at akuma.org
Wed May 21 21:24:42 CDT 2003
Mattias Campe wrote:
> yesterday, I did a presentation of Jabber at my university (actually
> it was a presentation for my RSS headlines jabber component) and they
> asked me how secure Jabber was. Unfortunately I couldn't answer that
> question very good. As I still need to give in my résumé, I would like
> to have some more information on this one.
> First, I've done some more research myself, but I still have some
> questions. From DJ Adams book, I know that there are 3 methodes to
> authenticate, namely plaintext, digest and zero knowledge. Is it
> correct that most clients use digest by default?
Currently, althought the XMPP working group has put effort into also
> Then there is SSL (Secure Socket Layer?) that you can use to encrypt
> the whole stream, am I correct? Still, I don't see that clients use
> this by default. What is the reason for this? I've read somewhere that
> it could be that this causes problems on some proxy servers, is this
> true? And does SSL provide end-to-end security or only
> client-to-my-own-server security?
SSL is expensive, and there isn't always an easy way to support it for a
particular client implementation. Also, SSL only secures a segment of
the transport, it is not end-to-end and thus there are no security
guarantees either that the traffic will or will not traverse the network
at some point in clear text, and also no way to verify the identities of
all the other intermediate routes so that you can decide if you want to
> Other two known ones are PGP and GnuPG, what's the difference between
> those two? Is a client supporting PGP compatible with one supporting
> GnuPG? How does this actually work? Is it encrypted at the client
> side, decrypted at the server side, to know the to address and then
> encrypted again to send it to the "other side"? What if the other side
> doesn't know about PGP, how those this side knows about that lack of
OpenPGP is what GPG supports, and there is existing end-to-end
encryption based on this. You do not have protection outside of the
payload, and this sort of asymmetric encryption (with public and private
keys) is much more computationally expensive in terms of bandwidth usage
processor usage - but at least the processing is done on the ends of the
network rather than the intermediate routes.
Normally OpenPGP support is indicated by signing the presence status.
The actual signed data is meaningless (it would be simple to forge by
just sending a previous signed block), but you can get the key id used
to sign the data from the signature block, and use this to retrieve the
key and start using it based on the level of trust in it.
> I read in "The Instant Messaging Standards Race: Comparing XMPP/Jabber
> and SIP/SIMPLe" from Jabber Inc. sth. about SASL (Simple
> Authentication and Security Layer) and TLS (Transport Layer Security).
> What is the principle of those two?
TLS is basically the standardized SSL. SASL is the IETF authentication
standard. The main point of SASL is that it provides a framework for
adding new authentication mechanisms, but also saves all the effort of
designing an authentication system and verifying the authentication
system is secure - you can just use an off-the-shelf library.
> What is meant by "end-to-end" vs "hop-to-hop" encryption, that with
> the first one even the server can't read what is in the message? But
> how do they know then where to send the message?
end to end means that only the sender and recipient require knowledge of
how to decrypt the message; hop-to-hop means the transport is secure,
but the intermediate parties (the servers) can see the contents. PGP is
used for end-to-end, while SSL/TLS is hop-to-hop.
I've always thought of the SSL choice being one that the administrator
makes, not one that the user makes. If you can connect to a server with
both a straight connection and with SSL, there is little reason to
connect _with_ SSL, because the administrator already has made the
policy decision that information is allowed to travel across the network
in the clear. SSL just uses more processing power, memory, and bandwidth
in this case. Just my opinion, though :-)
> Will jabberd2 support more security than the current jabberd server?
It already does. :-)
More information about the JDev