Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

Secure Internet Live Conferencing 61

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.
This discussion has been archived. No new comments can be posted.

Secure Internet Live Conferencing

Comments Filter:
  • 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
    • 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.
    • 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.
    • by Anonymous Coward
      We (some friends) have built up a VPN via FreeS/WAN and use a private ircd on one of our VPN-boxes. A little perl script helps us to keep the VPN consistent due to our dynamic IP's.

      This is one of the more secure ways of doing secure communication i guess, and very comfortable, as dcc works too etc (as long as no box is getting hijacked security is almost perfect).
  • 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.
    • 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.

  • Cross Posting (Score:3, Interesting)

    by jeremiahstanley ( 473105 ) <miah@mi a h . o rg> on Saturday January 26, 2002 @08:05PM (#2907816) Homepage
    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 ( [], and others I'm sure).
  • by Anonymous Coward
    This is great to see this get some coverage. I'e used this in the past, and it is excellent.

    The best I can say for encryption over IM's is the blaim plugin for GAIM. The only problem being that both sides must be using gaim + blaim.
  • Use stunnel, stupid (Score:3, Interesting)

    by smnolde ( 209197 ) on Saturday January 26, 2002 @08:12PM (#2907835) Homepage
    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.

    • by ( 40893 ) <> on Saturday January 26, 2002 @09:43PM (#2908058) Homepage
      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.
    • 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.
      • 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 could hold a lot of those AOL kiddies among other users.
        • 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.
  • by Anonymous Coward on Saturday January 26, 2002 @08:15PM (#2907841)
    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.
  • A better marketing department would have called it 'SLIC'.

    Or, to more accurately portray the likely discussion, 'SICK'.
  • 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.
  • I must step back and look at this from another point of view. What, precisely is the original purpose of this? Certainly I'm all for it -- the concept is incredibly cool -- but it somehow doesn't seem like something to replace IRC with. Frankly, nickname wars should be stopped with the nickserv/chanserv. You can't have the nickname blah? Try blah-, or ` or _ or whatever suits you. Get over it, or go to another network. Its not that big a deal. It seems to me that these clients will require a bit more power to them, and the protocol will as well. The encryption will make packets larger, and thus easier to use in a war style. Because I have been exposed to the not-so-nice part of IRC, it occurs to me to consider the possibilities here. Though anti-flood features can easily be implimented into the client, this is not the end of the possibilities. Another possibility to be considerred in the line of security is ip publicity. They seem to indicate that hostmasks will be available, which thus allows people to get at the ip address and use them for DoS attacks. Of course a masking procedure utilizing wildcards could be implimented as many smaller IRC servers have done. This provokes the possibility of multiple people on the same ISP from the same area with the same nickname showing up. These public keys are most likely obnoxious-to-remember alpha-numeric codes. Who wants that? Then again, if the client has a decent friends list, that, too, can be rectified. The next question I have regards forgery and trust. The server admins, who I will call opers for my convenience, will now have more reason to trust peoples' claims against others regarding abuse because there are now so few ways to perform abuse, and so much added security. But how easy will it be for someone to forge records of someone performing some sort of abuse? It seems to me that all of the information necessary will be provided in the /whois query for the purpose of identification. Will legitimate users be able to use opers as an effective means of cutting back on the inevitable abuse, or will it be too easy to forge offenses and thus make opers far too skeptical to help out in many ways? That's all I'll type for now, but these are certainly (in my opinion) issues for consideration.
  • I wouldn't mind to have simplified H.323, but who the hell needs reinvented wheel, when there is ESP for IPv6 and there is IPv6 with all buil=in goodies ?
  • This is slightly offtopic, but are there any free voice conferncing programs for Linux and windows? I've tried Gnomemeeting, but it uses a flawed system that doesn't work with NAT easily. I'd like to find a program that could do this, and use GPG keys for encryption for an added coolness feature. Any coming soon? Thanks,

    • check out Speak Freely - its site is here []

      it supports encryption and is multi platform.

      oh and if you're a windows developer the original speak freely site [] has lots of good points.
    • 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...)

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

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

  • BTW, for those who already haven't seen Gabber has GPG support. This should surely make some ppl happier, full-blown GPG in IM. -Pk
  • 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! []

To write good code is a worthy challenge, and a source of civilized delight. -- stolen and paraphrased from William Safire