[JDEV] Security in XMPP/Jabber: some questions

Perry Lorier perry at coders.net
Wed May 21 21:54:04 CDT 2003

Hash: SHA1

i'm not sure if I'm the best person to answer these but I'll try and
give it a go.

> 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?

To my knowledge most clients use digest authentication.  Debian
(errnoeously) ships with the plaintext module disabled, which prevents
users from creating accounts (as the plain text method is required to
set your password).  I believe there was some discussion about fixing

> 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 a nasty beasty.  To configure a server with SSL support you need
to get proper certificates which can be expensive, and just downright
irritating.  You can't properly vhost SSL for example.  Although, I'm
not sure how much of this applies to Jabber.

> 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 feature?

The data is encrypted client side, and decrypted on the other client.
This is called "End to End security".  The outer header isn't encrypted
so the source/destination is still known.  But the servers don't know
(or even care) whats in the payload.

I believe a client knows the other end supports encryption by checking
if their presence is signed.  After playing around sending encrypted
messages to a conference room and seeing the message "This message is
encrypted" it's obvious that you can send encrypted messages to people
who don't support it (or don't have the decryption keys) if you put
enough time and effort into 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 SSL version 3.  It got renamed for some reason.

SASL is a library which handles authenticating users.  You can (using
SASL) write a module which for example does authentication for kerberos,
or a "SecureID" style card, and then all the programs on the machine
that use SASL can now authenticate users using these new methods without
having to support it directly.  

> 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?

Hop by hop means that each server along the waydecrypts then encrypts
the message.  Any compromised server along the way can read any message.

End to End is where the sending client encrypts the message, and the
receiving client decrypts it.

You usually don't encrypt the header (with source/destination
information) for end to end encryption, just the payload (the actual
message itself)

> Will jabberd2 support more security than the current jabberd server?

I've not been following jd2 too much, so I don't know sorry.

> I hope sb. has some time to answer these questions (or some of them). I 
> don't need in-depth information, just enough to understand it :).


- -- 
Generic Fortune.
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Only when you are sure they have you, can you stop being paranoid


More information about the JDev mailing list