[JDEV] News: Company crippled over alleged ICQ leaks

[kadokev at msg.net]

> On Thu, Mar 15, 2001 at 09:05:56PM -0800, object at intelectronica.net wrote:
> > did anyone see this funny news item? gives you a pretty good
> > idea about why it is nice to have one IM system that allows you
> > to encrypt messages (and also makes it even more clear why a
> > technology market led by a bunch of incompetent playboys isn't
> 
> Actually, encryption wouldn't solve any of problems outlined in the article.

Thanks for being the voice of reason in this thread :)


> If you save logs of messages on a computer, that machine could be stolen and
> the logs passed on to others.

In this case, the logs were saved to the CEO's machine in cleartext. The machine
was compromised, and the cleartext log archive was copied off the system and
distributed. This same compromise could happen with any IM or email system
that permits archiving to the client PC, including Jabber clients.

>Encryption will stop people listening in to the message as it is sent, it
>won't solve any other problems

Any good encryption mechanism provides protection against outsiders sniffing
the stream in realtime.

SSL also provides for authentication that you are really talking to the server
you think you are, protects the username and password, and has the potential
for authenticating the client as well (client certificates). Using SSL
does not protect against compromised servers, nor against malicious server
admins spoofing, logging, or forwarding messages. This doesn't mean it that
SSL is bad, or should not be used, just that SSL has certain limitations.

Client-to-Client encryption, such as with PGP, provides authentication of the
client and protection against interception at the server as well. This still
allows for traffic analysis, and does not work well for conferencing. It does
not protect Client-to-Server communication (not yet).

In my opinion, SSL support (if I can ever get it to work) gives tangible
benefits with acceptable server overhead. PGP support in the client is less
of an issue in my particular applications, but is a nice option to have.


> (yes you could encrypt the entire log file but chances are the key will
> be stored on the machine some way obvious). 

In some cases, encrypting the entire log file can be more dangerous. Because
the stolen logs in this case were cleartext, the only authentication that they
are legitimate is the content and the fact that certain damaging content,
such as passwords, could be verified. But the eFront CEO claims that they were
edited before distribution. 'non-repudiation' is a feature of many encryption
systems, providing an ability to prove that the files are valid and were not
modified.
 

> In reality the only way to avoid this problem is to never save logs from
> instant messaging conversations. In the same way that its wise not to record
> phone calls its sensible to not record IM conversations (and probably wise to
> ensure that the client you use does not have the ability to save logs).

With a closed source client this can be enforced, and you can even have 
telltale that says 'the other party is recording this conversation'. 
 
With the open nature of Jabber, there is no way to enforce a 'no logging'
requirement for clients. We can choose certain supported clients as corporate
policy, but any client can be built to send the agent string of another.

Kevin Kadow