[JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
Joe Hildebrand
JHildebrand at jabber.com
Fri Jun 7 17:37:34 CDT 2002
Mike, we really appreciate the fact that you and others care enough to read
informational JEPs diligently, and discover potential problem areas such as
this. Sharing ideas like this is what the Jabber community is all about,
and leads to better technology for everyone.
Let me be a little more clear. We ARE actively working on crafting a solid
solution to the security issue. As soon as we are able, we'll publish a new
(still informational!) revision of the JEP documenting what we've done. In
the meantime, the existing JEP can be pulled, marked up, or left alone;
that's up to the JEP editor as far as I'm concerned. There still needs to
be a new, standards-track JEP for the community's use.
Jabber, Inc. takes security very seriously. All of our customers who are
using this feature know about the issue, and will get a patch when it is
available. We are actively working on a solution, and will have a fix out
as soon as possible.
--
Joe Hildebrand
Chief Architect
Jabber, Inc.
> -----Original Message-----
> From: Michael F Lin [mailto:MFLIN at us.ibm.com]
> Sent: Friday, June 07, 2002 9:31 AM
> To: jdev at jabber.org
> Subject: RE: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
>
>
>
> Joe, while I respect your collected response to my over-aggressive
> criticism, I am being over-aggressive for a reason.
>
> I understand that HTTP polling is still a developing concept
> and there have
> been bumps along the road. I'll agree that a standards track should be
> pursued, and I'll go along with your option #3 below. I hope that puts
> JEP-0025 to rest.
>
> What I find impossible to overlook is that Jabber, Inc. is publishing
> software with known and fairly severe security deficiencies.
> It's up there
> on a polished web site, with a cool-looking diagram, white
> papers and price
> tags ($25,000 if I'm not mistaken) to go with it. Granted none of this
> claims the client is secure, but neither does it provide any sort of
> warning that it is not a good idea to use this for sensitive purposes.
>
> I understand this is Jabber, Inc.'s business decision. But I
> believe it is
> an irresponsible business decision. In 2002, a hole of this
> magnitude in
> any moderately deployed software should be fixed within days
> or hours -
> even Microsoft is getting OK at this. Letting security fixes
> come through
> in the next "release cycle" is _so_ last decade. :-)
>
> Anyway, I hope you can take this as the one nugget of constructive
> criticism in all my ranting. Jabber, Inc. should get in the habit of
> pushing security fixes out quickly, because it will
> absolutely need to do
> so if and when Jabber gets really big. As you are concerned about the
> precedent of suppressing a JEP, I am concerned about the precedent of
> letting Jabber, Inc. become associated with insecure software.
>
> -Mike
>
>
>
> |---------+---------------------------->
> | | Joe Hildebrand |
> | | <JHildebrand at jabb|
> | | er.com> |
> | | Sent by: |
> | | jdev-admin at jabber|
> | | .org |
> | | |
> | | |
> | | 06/07/2002 03:38 |
> | | AM |
> | | Please respond to|
> | | jdev |
> | | |
> |---------+---------------------------->
>
> >-------------------------------------------------------------
> -----------------------------------------------------------------|
> |
> |
> | To: "'jdev at jabber.org'" <jdev at jabber.org>
> |
> | cc:
> |
> | Subject: RE: [JDEV] Implementation of JEP-0025
> (Jabber HTTP Polling)
> |
> |
> |
> |
> |
>
> >-------------------------------------------------------------
> -----------------------------------------------------------------|
>
>
>
> OK, as one of the authors of the JEP in question, I do have the
> responsibility so say this at least one more time, I suppose.
> I may not
> have done it on the jdev list, but I thought I'd gotten the
> gist across in
> foundation meetings.
>
> I realize that there are security holes in JEP-0025. I'm not
> convinced
> that
> any of the solutions that have been proposed are the "right"
> solution. I
> think we need to have a discussion about it. I think the way
> to do that is
> to have a new, standards-track JEP. Yes, it would be nice if
> I could get
> around to doing that, but I've been fairly swamped. If
> someone else could
> take a crack at a strawman, it would be helpful.
>
> Next, there *is no way* for me to modify our current product in the
> timeframes involved, due to our existing release cycle. Once
> we have a
> standards-track JEP approved, we'll see if we can support it
> in a future
> version. Because of this, it makes no sense to modify
> JEP-0025 to add any
> security measures.
>
> So, the foundation needs to choose one of these:
>
> 1) I can withdraw the JEP, in which case there will be no public
> documentation of the polling protocol. That doesn't seem
> neighborly to me,
> but I'm willing to bow to overwhelming pressure. Remember, it's
> INFORMATIONAL, which means that it documents an existing protocol.
>
> 2) Leave it as is. The council can decide whether or not to
> approve it.
> For informational JEPs, I think the criterion should be "does this JEP
> accurately portray the existing protocol." If the council
> decides that the
> criteria should include "... and we like it," then the council should
> reject
> it. If that happens, I don't know if it should stay on the
> JEP list or
> not.
> That's a process question.
>
> 3) Same as 2, but add some big bold letters that say "THIS PROTOCOL IS
> INSECURE. ITS USE IS DISCOURAGED." Frankly, I'm fine with that.
>
> I'd like to see more people document protocols that they are using as
> informational, to at least seed the discussion of what ought to be a
> standard. I'm concerned about the potential precedent of
> discouraging that
> behavior.
>
>
> <rant direction="aside">
> As I've said to a couple of people, I think that HTTP polling
> is a security
> nightmare, no matter how it's implemented. I've basically
> enabled people
> to
> thwart their firewall administrators. Yes, it's useful for those
> situations
> where the firewall is administrated by people that don't
> believe that the
> Internet can be used for legitimate business purposes, so we
> have to have
> it
> in our product mix. But its use should be discouraged where possible.
> </rant>
>
> <note relevance="low">
> I believe that if you do your polling over HTTPS, none of the stated
> attacks
> are possible, as far as I know. There are still some cool
> traffic analysis
> attacks, but no more so that with any Jabber session. If you
> have enough
> hardware to do HTTPS polling for a large number of users, well... wow.
> That's impressive, I'm sure.
> </note>
>
> > -----Original Message-----
> > From: Michael F Lin [mailto:MFLIN at us.ibm.com]
> > Sent: Thursday, June 06, 2002 12:52 PM
> > To: jdev at jabber.org
> > Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
> >
> >
> > I agree, unfortunately, we now have a new implementation
> based on this
> > "informational" JEP which is vulnerable to the same
> security problems. So
> > I
> > propose that the informational vs. standards track
> distinction is pretty
> > meaningless. Look at Matthias' comments - he used it for
> lack of anything
> > better.
> >
> > The authors of this JEP, in my opinion, have the
> responsibility of fixing
> > it. We have handed them several ways to do so. Jabber, Inc., in my
> > opinion,
> > has the responsibility of fixing its web client before its
> users using it
> > for "financial applications" get burned.
> >
> > -Mike
> >
> >
> >
> > |---------+---------------------------->
> > | | "Peter Millard" |
> > | | <me at pgmillard.com|
> > | | > |
> > | | Sent by: |
> > | | jdev-admin at jabber|
> > | | .org |
> > | | |
> > | | |
> > | | 06/06/2002 01:05 |
> > | | PM |
> > | | Please respond to|
> > | | jdev |
> > | | |
> > |---------+---------------------------->
> > >
> --------------------------------------------------------------
> ---------
> > -------------------------------------------------------|
> > |
> > |
> > | To: <jdev at jabber.org>
> > |
> > | cc:
> > |
> > | Subject: Re: [JDEV] Implementation of JEP-0025
> (Jabber HTTP
> > Polling) |
> > |
> > |
> > |
> > |
> > >
> --------------------------------------------------------------
> ---------
> > -------------------------------------------------------|
> >
> >
> >
> > Mike -
> >
> > > I agree, and I strongly recommend against the use of
> JEP-0025 as-is
> > > for any remotely sensitive purposes.
> > >
> > > We have been aware of the security problems for two
> months and have
> > > proposed multiple viable solutions, but nothing has been
> fixed. This
> > > JEP either needs to be fixed or withdrawn.
> >
> > *disclaimer: I am employed by Jabber, Inc* :)
> >
> > JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards
> > track.
> > The whole idea behind informational JEPS is that they allow
> companies
> > (like
> > Jabber, Inc.) to document the protocol extensions that they
> build, so
> > other
> > people in the jabber community can use and build other
> products to them
> > (if
> > they so desire). It's unlikely that this JEP will change since it
> reflects
> > a
> > currently deployed product (good bad or ugly :).
> >
> > Someone needs to take JEP-25 as a base, and create a new
> STANDARDS track
> > JEP
> > that fixes the security holes in the current implementation
> and submit
> it.
> > Then client authors (like myself) can choose to implement
> either JEP-25,
> > the
> > new standards JEP, or both.
> >
> > Hope this makes sense.
> >
> > Peter M.
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
> >
> >
> >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
>
>
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
More information about the JDev
mailing list