[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[JDEV] Jabberbox validation, WINE and JabberClient..



> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> Jeremie
> Subject: Re: [JDEV] Transport<->Jabberbox validation..
> Awesome, sounds like fun :)

	Didn't have any time last night to do a checkin, look for an actual working
version tonight, that will allow sending/recieving of messages..  No 'Buddy
Lists' yet, but I'm trying to make sure all of the backendstuff isgoingto
work OK.  I need to add more intelligent error handling on the socket
connection itself, like catchinga disconnect as soon as it happens,and not
several seconds later..  (Ok, so I'm anal and want to catch things as they
happen,and not when the program happens to notice them..  Sue me..;-P )

	I have donesome thinking of how my client will run under Wine, and I'm not
sure how it will..  Currently, it resides in the system tray just like all
of the other messaging products, and I've never tried to run system tray
apps under Wine..  How does Wine treat them, as it doesn't have a System
Tray to put it?  Anyone know?

> Jabber takes the same approach as email when it comes to other servers.
> Basically, the JabberBox accepts incoming connections from any transport
> that connects to it.  It just operates as a "router" and tries not to get
> involved in the data that it's routing, and the Jabber Transport will just
> deliver the data to the client.

	Hrm..  I think we need to sit back and think about this..  Since we're
going to allow admin messages to come back and forth thru the transports, we
need something a little more then SMTP mail transfer currently does.. At a
MINUMUM, we should:

Do a reverse lookup on the IP to ensure that the transport IS coming from
where it says it is.

Upon connection, have some sort of XML handshake that generates a unique
'Key' that will be used for a random amount of time.  Perhaps this should be
done thru a 'validation socket' that is different from the server socket.
The Client communicating will request a key, and we can then transfer it on
another socket (Perhaps HTML via an SSL socket?).  And the server should
send it to the client, not have the client get it, and use the cached IP
address, NOT the name, as DNS spoofing could be used to get around it if
sending to the name intead of the IP.

	I may be seeming paranoid, but I DON'T want to see any simple hacks on
www.rootshell.com to allow attacks on Jabber users.  If that happens,
thefirst time it's announced will cause knowledgable users to flee like
teens from hard work.. ;-P

> Jabber is not going to inherently be any safer than email is, but if you
> want guaranteed safety it should be easy using mod_digsig and a client
> that understands crypto :)

	But we need to do something..  As said, if we DO allow admin messages to
flow, weneed to secure these.  At least make it REALLY hard to hack it..

> Besides, because of Jabber's fundamental design that allows the
> transparent connectivity to other IM systems, you have to allow for the
> levels of security in those systems, which might as well not be considered
>  "security", *grin*.

	Yes, but I don't think that any external system should be able to do admin
messages myself.. ;-P

--
Thomas Charron
United Parcel Service
Northeast Region
"Moving at the speed of a T3 Trunk Line!"