[Council] new JEP -- position paper needed!

Joe Hildebrand jhildebrand at jabber.com
Tue Apr 2 10:29:47 CST 2002


If this doesn't make it to the list, could someone forward it, please?

Replies in-line.

Mike Lin <mikelin at MIT.EDU> writes:

> > "In some browser/platform combinations, sending cookies is not
> > possible due to design choices (bugs?) in the browser. Therefore,
> > a work-around was needed to support these platforms."

> I presume the "work-around" this refers to is the sending of the
> Session ID in the payload of the request instead of in a standard
> responding cookie header. If so, this should be stated more clearly.

Yes, and yes.

> I don't quite understand how the browser is relevant here. Why is
> the web browser's (a UI) ability to send cookies relevant to the
> design of a Jabber client? Recalling that this JEP describes the
> JabberIM implementation, one might conjecture that your
> implementation uses WinInet or some other prepackaged HTTP component
> which does not like the cookie header. Again, since this JEP is
> informational, I won't argue directly against this hack, but if my
> conjecture is correct (or even if it's incorrect) it would be useful
> to clarify this point in the JEP.

The browser is relavent here because this protocol came about a a
requirement of our web client, not JIM.  The actual client-side
implementation is a small Java applet, running in the browser, that is
doing the polling.  The browser has a significant effect on the
behaviour of the JVM, leading to lots of unanticipated modifications
of HTTP requests made from Java.  So, since using cookies in the
standard way is impossible for some client implementations, the
protocol had to change.

Another way of doing this would to have been to send name/value pairs
of URL encoded information, like a normal POST.

> Also wouldn't it make more sense to return transport errors in the
> HTTP response code instead of an overloading of the session ID?

Probably.  I At some point it was probably easier to implement this
way.  I don't recall what lead to this decision.

> > "The best solution for sites that are concerned about security is
> > to run their own Jabber server, either inside the firewall, or in
> > a DMZ [1 ] network. Failing that, allowing internal clients to
> > access external Jabber servers poses less risk today than most
> > email access methods, such as POP3."

> Unless there is something I am flagrantly overlooking (which is
> certainly possible), this protocol is rather obviously vulnerable to
> hijacking by an eavesdropper, in an attack much easier to achieve
> than a similar attack against a single long TCP
> connection. Admittedly, our existing security over such a connection
> leaves something to be desired, but this protocol seems to me to
> leave much more.

The whole point of this protocol is anti-security, frankly.  We are
actively defeating the will of the firewall administrator.  Anyone who
cares about security will just use 5222/tcp, or 5223/tcp (ssl).

> I would *strongly* recommend, even though this is an informational
> JEP, adding some kind of mediocre session authentication by means of
> a crytpographic hash over the user's password and a request sequence
> number of some sort. I think there are very cheap ways to at least
> bring the security of this protocol basically on par with what we
> have now.

That's a good idea.  We'll look into it.

> And now that you mention POP3, it seems to me it might actually work
> quite nicely to base a proxied protocol on Sendmail/POP3 instead of
> HTTP (assuming proxies open 25 and 110 as well as 80, which I
> understand might not always be the case, but bear with me for this
> thought experiment). Security aside for a moment, this would be very
> nice because this pair of protocols is already designed for the kind
> of polling we are trying to do, albeit more slowly. We could even,
> if we so chose, rather elegantly build framing into the protocol by
> putting each packet into its own "e-mail". Now as for security,
> clearly POP3 is pretty bad because it transmits the password in
> cleartext. But so long as we are only looking to trick a proxy
> server, we could modify the semantics of our protocol, such that the
> password sent in each request is a cryptographic hash of the user's
> password and some request sequence number, as I described before.

We're not guaranteed that 110/tcp or 25/tcp will be allowed out.
80/tcp is about the only thing that is guaranteed to work on all
Internet-connected boxes.

> Finally, I would like to see more specifics about your implementation.
> In particular, some suggested polling intervals might be helpful (1Hz?).

This is configurable for us.  For demos, 1Hz works fine.  In real
life, I think that 1/30Hz or 1/60Hz wouldn't be noticeable.  The
implementation could also choose to vary the poll time, based on
current state.  For example, poll once per minute, unless there is a
chat window open, then poll once every 10 seconds.

> It seems that several points in the protocol besides those I pointed
> out are a result of the specific needs of JabberIM, written in
> Delphi (I think) on Win32. For example "Both the request and
> response bodies are UTF-8 encoded text, even if an HTTP header to
> the contrary exists." I would like to see these clearly pointed out
> as a requirement of your implementation and not necessarily of an
> engineered design.

Hm.  I'll take a look at that.  The entire thing is informational; I
wouldn't expect that a standards-track protcol would look like this.
The protocol as described represents the end-point of a fairly
drawn-out trench war to get product to market.  :)

> Thanks,
> Mike

Thank you!

-- 
Joe Hildebrand
Chief Architect
Jabber, Inc.
http://www.jabber.com/




More information about the Council mailing list