[standards-jig] JEP-0025 "Jabber HTTP Polling": security

M.Kiesel maqi at exmail.de
Mon Apr 29 16:28:58 UTC 2002


I have some scripts that implement Jabber HTTP Polling as described by
JEP-0025 almost done. I don't want to release them right now for the
mechanism described in JEP-0025 is extremely insecure (see Mike Lin's
posting in the council mailing list:

Two things should be improved:
1. Security: cookie based connection tracking is vulnerable to sniffing
2. (Future) compatibility: currently there is no way to determine which
HTTP Polling protocol is used (well, there is only one at the moment, but
this should change soon ;-).

Mike's suggestion (username/password/seqnum hash per request) certainly
improves security but is impractical since it requires the user passwords
to be stored in cleartext on the server. Also it would be good if the
wrapper scripts had not to deal with the server's internals.

So, here are my thoughts:

1. Security. Use an approach similar to the one used with zero-knowledge
authentification in jabberd itself:
   - client generates some magic (M0)
   - client hashes this magic for example 100 times (M100)
   - client sends M100 to server upon initial request (server stores M100)
   - upon next request, client sends M99 to server - server hashes M99
     resulting in M100, verifying the client's identity
   - and so on...
   - client sends a newly generated M100' to the server when M1 is
This should be relatively easy to implement and make the connection as
secure as a standard Jabber connection via port 5222 is.

2. Compatibility. Unfortunately JEP-0025 does not provide any version
exchange capabilites so implementing a client that does support both the
hashing extension and the cookie based approach is not possible (as far as
I can see). I would propose some simple approach, see examples below.

1. Initial request

POST /wc12/webclient HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: webim.jabber.com
Content-Length: 105+n

  <stream:stream to="jabber.com"

 C0: "Cookie 0" (= new connection)
 Nae01d95cd6f28b1c9873708892714696810d866d: "New hash"
 #: "End of caps/commands list"

2. Initial response

Date: Fri, 15 Mar 2002 20:30:30 GMT
Server: Apache/1.3.20
Content-Length: 138+n
Content-Type: text/xml

  <?xml version='1.0'?>
  <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
  xmlns='jabber:client' from='jabber.com'>

3. Next request

POST /wc12/webclient HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: webim.jabber.com
Content-Length: 117+n

  <iq type="get" id="WEBCLIENT3">
  <query xmlns="jabber:iq:auth">

 Hae01d95cd6f28b1c9873708892714696810d866d: "Next hash"


4. Next request (new hash)

POST /wc12/webclient HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: webim.jabber.com
Content-Length: 117+n

  <iq type="get" id="WEBCLIENT3">
  <query xmlns="jabber:iq:auth">

I know that C...,H...,#,... approach is not too good-looking but it does
not require the wrapper to need XML parsing capability - and it should
suffice :-).

Normally a cookie is not needed for the server can determine the
connection/session the request belongs to from the hash. Perhaps one could
leave it away.



More information about the Standards mailing list