Secure Internet Live Conferencing

An Anonymous Coward writes: "Newsforge has an article about new generation secure chat protocol called SILC (Secure Internet Live Conferencing). The article features the protocol and its features like secure file transfer. Interesting article and very interesting protocol." We posted a story about SILC last year; looks like they've come a long way since then.

Comments

Secure talking not very common

[Wizard of OS]

Somehow, it is quite hard to _really_ initiate a secure communication without much work. You can ofcourse:

- send e-mail signed with PgP, but that doesn't really fall under 'instant-messaging' or 'conferencing'
- run a SSL-enabled IRC client and connect to a secure IRC network (lot's of compiling and patching here)
- use Licq's OpenSSL features ... but since no certificates are used during instantiation, it could still be hijacked
- using 'talk' on a machine that is accessed through SSH ... hardly to call userfriendly

I must note that I haven't read the article, but a standarized, easy, and secure (meaning that Man-In-The-Middle attacks are not possible due to strict certificate-based identity checking) conferencing programs could be the next Big Thing

Re:Secure talking not very common

[Shiny Metal S.]

Somehow, it is quite hard to _really_ initiate a secure communication without much work.

I won't say anything insightful here, but when I need a Secure Internet Live Conferencing(tm) to safely talk about some top secret stuff with people I work with, then we just connect to our server with ssh, run BitchX and use a local IRC daemon. Quite easy and secure for me, especially when most of the work is in shell anyway.

Re:Secure talking not very common

[Jubal Kessler]

Or you could just connect via ssh to a localhost-only IRC server and yak to friends there ..

Link a few of those localhost-only IRC servers together via ssh tunnels, and voila, secure network. However, accounts on the machines hosting the IRC servers are required.

Given the above, one could create an account with the shell pointing to an IRC client binary, so specific user accounts wouldn't always be necessary.

The pro: Don't have to retrofit existing IRC clients on any platform for SSL or other PKI compatibility. Just ssh forward ports 113 (identd) and 6667 (ircd), and point your favorite program to localhost on 6667. Or whatever port on which you've got ircd listening.

The con: You need an account on the localhost-only IRC server's host.

Cross Posting

[jeremiahstanley]

I'm gonna be called a troll for this...

But do we really have to cross post everything that gets posted on Newsforge? It is already sydicated everywhere else (linux.com, and others I'm sure).

Use stunnel, stupid

[smnolde]

stunnel helps to encrypt normally non-encrypted data streams.

I've got my own ircd which I require the clients to use stunnel or an ssl-enabled client to connect. Soon, I can limit access purely by accepted certs, thereby keeping lusers out.

Of course the same can be done with OpenSSH. I use that at work to bypass my office firewall and use my home cable connection for a proxy to usenet, email, and other service. The best part of this is I can bypass my ofice proxy so they don't record where I netsurf. it looks a lot like a bunch of ftp and telnet to them.

Re:Use stunnel, stupid

[BigJim.fr]

You are merely protecting the path between your workstation and the server through which you access the IRC network of your choice. Don't forget that IRC is a network, and that that it's distributed nature puts the security of your communications beyond your own control. Tunneling will not change much to IRC security. What would noticeably increase privacy would be encrypted discussions between client side scripts communicating through DCC. It would add a layer and would use the IRC server as a directory and session initiation environment.

Re:Use stunnel, stupid

[acidblood]

You don't get the point.

You can't simply fix a broken protocol by tunneling it over a secure connection. IRC wasn't made with security in mind, and it shows. Stunnel is no more than a temporary and very dirty hack, until something better shows up. That might be SILC, or this project I've started along with a few other IRC addicts: CIRCUS.

Then there's other fixes regarding network scalibility, for instance. And don't forget the boom of IM in the last few years, which has shown quite a few features which IRC is lacking, and an updated protocol might take a shot at improving user experience, going way beyond what IRC can offer.

Re:Use stunnel, stupid

[Kool_Cat]

And don't forget the boom of IM in the last few years, which has shown quite a few features which IRC is lacking...

If anything, most of the IM software seems like a stripped-down IRC client: Connect to a server; check your notify list; send private messages to people; create "chats" and invite your friends in; send files to people on your notify list (I've never used MSN or AIM, do they even support file transfer?); and then a few external program launching that could easily be done by a client script.
So what exactly is lacking in IRC? IRC has public "channels" as well as private chats, direct-connect chats and file-transfer, support for many clients and bots, even server-run moderation by control of the user. Will you miss your pretty flower? We could still use those sounds that everybody loves in IRC...

All one really needs is a small notify list window (with right-click action) add-on for mIRC and suddenly people are using IRC again :) (hmmmm...I might just do that actually...) Then all that must be done is to link all those networks together, I'm sure irc.aol.com could hold a lot of those AOL kiddies among other users.

Re:Use stunnel, stupid

[smnolde]

Easy... I'm not doing anything special with the ircd. I'm only allowing the connection to the ircd through stunnel. This makes it a layered application. I can't code my way out of a wet paper bag so I can't contribute. However I am an engineer so I takes bits a pieces and use them to best suit my needs.

Stunnel is set up to listen on one port and forward the decrypted data to the port where the ircd is listening.

My setup isn't a solution, but it's a combination available software; I'm not integrating one into the other.

Re:Use stunnel, stupid

[acidblood]

Many things could be done.

First, an ICQ-style notification list. That alone, although it only depends on a client mod, would be great.

Second, in IRC, you can never be sure you're talking to the right person. The nick might have been hijacked or something. Having a central database of nicknames would solve the problem. Yeah, there's NickServ, but it's also a hack -- IRC needs an integrated authentication service.

Plus, people won't be using text interfaces for long. Once there's bandwidth enough, people are going to use voice and video, and save by a dirty hack IRC can't expand into that. Any IRC-replacing protocols must expand easily and cleanly -- you can't tell what the future holds for more efficient means of communication.

Being able to authorize people to go into your notify list or not is also a desirable feature for some.

I don't want to turn IRC into ICQ. I want to grab the best of both worlds into a single application, with the addition of cryptography and network scalibility enhacements.

Jabber has got signatures/encryption as well

[Anonymous Coward]

Jabber is an openly-developed, XML-based messaging platform. As anyone might expect, it has built-in security features, from SSL server connections, to PGP signatures/encryption. A number of clients is available for various platforms.

Small downside

[Cheshire Cat]

No more AOL chat rooms for Biff the big hairy trucker pretending to be Buffy the sweet little virgin. Now he can securely coerce little kiddies to visit without worrying about being traced.

While this is a legitimate issue, I think its a negligible one for two reasons: 1) most people like Biff get caught in sting operations, or when the kid has second thoughts and tells their parents. 2) At my office, I know our network admins sometimes get bored and grab packets from people's computers to see what they're up to. I'd rather not have someone in a filthy Doctor Who T-Shirt reading my Instant Messages. To me, this application of said protocol far outweighs the chance a child molestor will be able to cover his tracks a little bit better.

Betther than SSH/Stunnel/etc. + IRC

[libertynews]

The reason why this project is so good is that it just works. you install the client and you can connect securely without screweing around with configuring a dozen different programs, etc. I had it up and running in the time it took to download the .rpm and install it.

Good, but Trillian may be simpler

[internic]

I've been using Trillian for a while. It's a free (like beer) mult-medium chat client for Windows. The newest version supports 128-bit blowfish encryption for chatting over AIM and ICQ networks with other Trillian clients. This is achieved by using a key exchange method like Openssh. It is far from mature. As the newsforge article notes about other such systems, it lacks the authentication and key management aspects, so it is not really very secure yet; however, those could be achieved with relative ease, I beleive, and the general method might be a lot more viable for a transition from current insecure systems.

The point is that the way Trillian does it, all messages are encrypted into ascii-armored "messages" that are sent through preexisting messging protocols. A new protocol would probably be better, but it will be hard to get people to switch. Plus you need servers, and you will likely run into the same problems of the big companies working against interoperability. With Trillian, I can talk securely to those who care and have the client, and still talk to everybody else, and it doesn't take special servers, so we don't have to start our own or wait for AOL to finally think that security might be a good thing.

My point is not, "Hey everybody, switch to Trillian," but rather that the system of changing the client operation and leaving the protocol the same may not be as good as a completely redesigned protocol, but it may be more workable. ...However, if you use Windows, do check Trillian out!

Re:Free Voice Chat Program?

[Kirkoff]

Hi David,
There is actually an older program named Speak Freely. I've used it for a number of years and still love it. It runs on *BSD, Linux, Solaris, Windows and probably others. The windows version has a pretty well designed GUI, but the Unix version is CLI based. It comes with two GUI interfaces in the source's CONTRIB dir which are written in TCL. It has a number of encryption modes (4 I think) including using PGP to do the encryption. It also has many audio compression modes making it suitable for anything from High Bandwidth applications all the way down to a 2400bps modem (Really!). The codecs are GSM, ADPCM, LPC, LPC-10, and Simple. Simple just drops certian bits and can be mixed with any other codec. You can run it with out audio compression as well. If you're a fan of amateur radio, this program runs the links of the IRLP project. Very cool stuff.

My personal favorite way to run it is to have my linux box run a reflector and then have people connect to that and that way I can have multiple people in my conversation. The program is due for a bit of an update, anyone want to volenteer? (I looked at the TODO list and it's all beyond what I can do...)

--Josh

Re:Free Voice Chat Program?

[redcliffe]

Another thing that would be cool would be a KDE frontend. :-)

What's the best codec for using with dialup modems? Also is there a way to see if you're friends are online? Thanks,

David

Re:Free Voice Chat Program?

[Kirkoff]

I'd have to agree about a KDE front-end. Maybe I should learn enough QT to do just that... ;-)
The best Codec for dialup is GSM. It's compressed 5:1 so that you can send it over 19.2kbps. I use IRC or Everybuddy to see if my friends are online. You just put in their hostname/IP address to connect (or they put in yours) so you can give that info over any IM protocall you want. Perhaps a Jabber extention would be in order...

--Josh