[JDEV] Jabberbox validation, WINE and JabberClient..

[Jeremie Miller]

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

Wow, I can't wait!  Xool!

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

I've wondered the same thing... maybe I'll grab a snapshot of wine and try
it out tonight...

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

Admin messages?  Well, I'd definately like to restrict ANY sort of admin
functionality to ONLY _directly_ connected and _authenticated_ admin
users, not via any transports.  We'll touch on this later when there is
actually something to admin :)

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

Icky... that would break SO many things and it doesn't really offer any
more security(you can't trust TCP at all, its all breakable if you really
know what your doing and many do).

The other problem is that even if the reverse matched the connected IP and
provided name, it might be a rouge transport that sends encapsulated fake
messages, and Jabberbox doesn't look at the actual data it's handling, it
just passes it on like any good router.

> 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

I get spoofed email and spam all day, but I don't see those on rootshell
:)

We need to be very careful to not allow any "access" to personal
information or holes in clients that would allow access to a users
computer.  Other than that, we will be dealing with the same "trust"
issues that email has.

There is a whole bucket of worms here waiting to be dealt with. I think if
it's made clear up front that if you need absolute security in your
instant messaging you should use one of the secure clients that can sign
messages and login via mod_digsig, otherwise the messages you are
receiving may NOT be genuine.

Jer