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

Thomas Parslow (PatRat) tom at almostobsolete.net
Mon Apr 29 18:52:24 UTC 2002


Hi,

I'm not at all experienced with security stuff so there's probably
something I'm missing but how about sending a hash of a randomly
generated key with each request along with the key from the previous
request (not hashed)? This would allow the receiver to verify that it
is still talking to the same sender.

I guess this still allows someone to intercept a request, keep the
key from the previous request the same but change the hash and thus
takeover the connection but if they can already do that then can't
they just replace the contents of each request with their own data
(such as a change password IQ)?

Thomas Parslow (PatRat)
E-Mail/Jabber: tom at almostobsolete.net
ICQ: 26359483

M.Kiese wrote:

> Hi!

> 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:
> http://mailman.jabber.org/pipermail/council/2002-April/000245.html).

> Two things should be improved:
> 1. Security: cookie based connection tracking is vulnerable to sniffing
> attacks
> 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
>      reached.
> 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

> C0,Nae01d95cd6f28b1c9873708892714696810d866d,#,
>   <stream:stream to="jabber.com"
>   xmlns="jabber:client"
>   xmlns:stream="http://etherx.jabber.org/streams">

> [comment:
>  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

> C7776:2054,#,
>   <?xml version='1.0'?>
>   <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
>   id='3C9258BB'
>   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

> C7776:2054,H767425dde2d5512172662986b34d3ef9d3e911d0,#,
>   <iq type="get" id="WEBCLIENT3">
>   <query xmlns="jabber:iq:auth">
>     <username>hildjj</username>
>   </query>
>   </iq>

> [comment:
>  Hae01d95cd6f28b1c9873708892714696810d866d: "Next hash"
> ]

> (...response...)

> 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

> C7776:2054,H70c87a5da2f863a8a91940d812d48137ee055163,
> N374b865bb4e96c0033706d29134eade5279f1908,#,
>   <iq type="get" id="WEBCLIENT3">
>   <query xmlns="jabber:iq:auth">
>     <username>hildjj</username>
>   </query>
>   </iq>



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

> Comments?

> Regards
> M.Kiesel




More information about the Standards mailing list