Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Secure IRC? 130

Posted by michael from the /join-#security dept.
priikone writes: "IRC has had a lot of problems related to security and network scalability in the past, and recently as well. However, there is an alternative -- secure alternative to IRC; the Secure Internet Live Conferencing (SILC), which has all the same features IRC has, with addition of superior security, and hopefully more scalable and powerful network topology. It is for all those who cares who's listening. It works, and is of course all Open Source." We posted an article about another secure IRC system last year.
This discussion has been archived. No new comments can be posted.

Secure IRC? More

Secure IRC?

Comments Filter:
  • I seem to recall an old 2600 that had an article about running a secure, non-public IRC server for friends or whatever. bascially, what it amounted to was a box running no public service except ssh, that people logged into. or it was a dual homed host that was attached to another network (non-internet) running ircd.

    It obviously wasn't an open system, and you have to trust the people you are giving accounts to.
  • at one point I wrote a special irc client that used existing irc protocols but encrypted text using your key into a viewable ascii range so that it could be successfully passed over irc. no special mods, and of course the message was encrypted all the way through the network. so even though the underlying protocol wasnt secure. secure messages could be sent with a minor loss in performance due to extra characters as a result of the encryption scheme. clients who didn't know your key would see garbage. unencrypted messages would show up as normal. It was pretty cool, it worked for several years before I left irc. getting people to switch to a new protocol/network is difficult. people a) don't like change and b) are afraid to lose the connections they have on irc. So unless you convinced EFNet to shutdown its irc services and switch to SILC or something, nobody would want to take the risk and sit around on empty channels until everybody filtered over. I think a much better solution is like the one I had. Just use some extra functionality on clients without changing the RFC for IRC.
    • Better yet would be to write a proxy that takes standard IRC client connections and then connects to the IRC server, encrypting/decrypting messages on the fly. Of course, then you're only as secure as the connection between your client and the proxy and DCC is still just as bad (though the proxy could intercept the DCC as well) Rich
  • Austnet (http://www.austnet.org - irc.austnet.org:6667) has had their virtual world system running for a while now, it masks all the hostnames and ip addresses effectively ie. dialup12.yourisp.com.au becomes vw-293.yourisp.com.au

    This works well, bans etc are still in place - I believe you can get the source for the server from their website as well.
    There are a few methods of getting users IP addresses: reversing the hash algorithim that generates the vw address in the first place, and initiating a dcc connection are two common methods. But for all intensive purposes it works quite well.

    At one stage some members of a channel I was in set up secure IRC using ssh2, not sure exactly how it works. caddis on efnet may give you more information.
    • But it is impossible to develop a hostmasking scheme that is one-size-fits-all.

      In the AustNet example, the hash is deterministic, in that a hostname will always hash to the same vw-XXXX value. It is therefore possible for a patient attacker to observe people who switch off the masked mode and reveal their true addresses, and build a lookup table which can be later used on other people from the same ISP.

      Worse than that is what happens when a user's IP address does not resolve to a host. Then only one quad of the IP is hidden, meaning that it really isn't too hard to hash every possible matching IP address (256) with every possible key (dunno about this, I've not read the source).

      The answer to the above two is to use a non-deterministic hash (the same host will not always produce the same hash), but then that breaks bans and bots that recognise people by their (static) host.

      There is no generic answer that is perfect, because people are used to being able to see hostnames on IRC and have moulded their activity to this ability. If IRC had not offered hostnames from the start this would not be a problem.
  • Sounds like a good idea for the most part... I wouldn't think that the general public would be very interested in somthing like that, just sounds like a bit more of a hassle. However, this would be a great thing for large networks and Corp. intranets for real-time discussions or online classrooms yadda-yadda, the list can go on.

    My point is for private group use sure - looks great... for public personal use for the masses... ehhhhh ill stick to my BX - if i want something secure I'll send a pgp encrypted e-mail.

    .ph0x
  • You could write public key encryption into the client itself, or easily script it in. Of course other folks in a channel would see only gibberish, but you could do it on a /msg by /msg basis by user as well.

    I was actually thinking of implementing IKE in an XChat script awhile ago. It just wasn't worth the time for me to pursue, however.

    • IDEA-encryption is actually already implemented on many clients: irssi [inside.org], irchat [people.ssh.fi] and ircii too (can't find a link though). This is technically far more better than SSL-encryption to the server since it encrypts end-point to end-point.
    • >You could write public key encryption into the client itself, or easily script it in.

      There really are projects trying to do that.
      You just need a PGP-like open-key system and a few lines of script to glue it into your client.

      IMHO that's the best solution because it uses the existing IRC network (with all its advantages and disadvantages) and probably even your favourite IRC client (if it supports scripts/plug-ins), but enables you to communicate with strong encryption.
    • Yup. And if you implement IKE, check it out, the keys get exchanged automatically. Easy to use if you configure a (different) shared secret between you and each of your friends/channels.

  • Great! (Score:3, Interesting)

    by SnapperHead ( 178050 ) on Thursday August 09, 2001 @08:50AM (#2116806) Homepage Journal

    We where just talking about setting up something like this for our private core developer mettings. Nothing that secret happens there, but be had a small problem a few weeks ago. We had someone hijack someone elses connection. We are still tring to figure out what and how it happened.

    Using encryption will prevent this. Not only sniffing, but connection hijacking. (At least I would think :)

    I think a secure IRC network is needed and has been needed for a long time. Too many people tring to pretent there someone else. If you know there key finger print, you can compiar them.

    Time to download it and give it a try :)

  • I currently have a pretty secure IRC setup, when I connect to IRC, I pass my connection through my NetBSD gateway, well as the IRC related packets are passed, they are sent through a program called "Stunnel" Stunnel provides SSL encyrted connections to IRC, thusly my connection/text is always pretty damn secure.
    • I currently have a pretty secure IRC setup, when I connect to IRC, I pass my connection through my NetBSD gateway, well as the IRC related packets are passed, they are sent through a program called "Stunnel" Stunnel provides SSL encyrted connections to IRC, thusly my connection/text is always pretty damn secure.

      Hee hee. Right, until it gets to the server and is sent (unencrypted) to everyoen on the channel. IRC will never be end-to-end secure unless we build some sort of PGP-style layer on top of it. Or we could just use SILC...

      -zack

  • A bit misleading subject (Score:2, Informative)

    by Anonymous Coward
    Well, the subject (edited by Slashdot) is a bit misleading. SILC is NOT IRC and is NOT IRC compatible. SILC is independent protocol. I guess the subject was first "A Secure Alternative To IRC?".
  • IRC is a denzien of hackers, pirates and kiddieporn scum.

    Maybe you are one of the 500 people who actually chat on IRC, good for you. 90% of the traffic is warez and porn. These people could care less about security and prefer anonyminity for obvious reasons.

    Sorry to burst the bubble.

    • Re:You cannot secure IRC (Score:5, Insightful)

      by RedX ( 71326 ) <redx@nospam.wideopenwest.com> on Thursday August 09, 2001 @09:41AM (#2136103)
      IRC is a denzien of hackers, pirates and kiddieporn scum.

      Sounds just like just about every ignorant Internet critic, RIAA or MPAA member, government official when trying to justify DMCA or some other piece of legislature/censorship. Get a clue, troll. Just like every other area of the Internet, IRC does have its "hackers, pirates, and kiddieporn scum", but it also has a great array of technical resources and general chat areas. I don't know of many other places where I can drop in and get real-time support from peers when trying to chase down a network or OS problem. Hate to burst your bubble, but many people might think of IRC and Usenet to be the bottom of the Internet barrel, I find them to be two of the most useful technical resources I have at my disposal.

    • IRC is a denzien of hackers, pirates and kiddieporn scum.

      Did you mean denizen? Denzien doesn't appear to be an english word. Assuming you did mean denizen, you still used it incorrectly- your sentence should be "IRC's denizens are hackers, pirates, and kiddieporn scum." Denizens are the things which inhabit, not that environment which is inhabited.

      And yes, some people do actually chat on IRC. Over in #smokedot on Slashnet.

    • IRC is a denzien of hackers, pirates and kiddieporn scum.

      Maybe you are one of the 500 people who actually chat on IRC, good for you. 90% of the traffic is warez and porn. These people could care less about security and prefer anonyminity for obvious reasons.

      yeah sure, no one using except for people breaking the law use crypto...get real

  • SSL IRC Connections (Score:3, Informative)

    by OpCode42 ( 253084 ) on Thursday August 09, 2001 @08:53AM (#2121181) Homepage
    I thought UnrealIRCD already had ssl connections, and XChat 1.6.4+ have an option to connect in ssl mode.

  • IRC can be fixed easily. (Score:4, Insightful)

    by Lumpy ( 12016 ) on Thursday August 09, 2001 @08:44AM (#2123195) Homepage
    1. add an authenticate system like slashdot, but does not release any info - I.E. bubbles is your nick? well then you are bubbles and that is all that is released.

    2. BLOCK ip address discovery. The Irc servers you are connected to dont have to tell everyone that you are at 192.168.1.1 and if you dont release what IP you are at then the script kiddies and other tripe cant attack.

    IRC was a great idea, when people on the net had a maturity level higher than that of an 8 year old. Today we have to give up those niceiteies of yesteryear to give a nice big thump on the head of the idiots and morons.... but the coolest thing is that the above ideas would bring back registered nicks.
    • Those two points have already been implemented on IRC in some servers.

      1) An authentication system exists in the form of nickserv (although optional, can be made to prevent other users from using your nick), and no other information would be released if the user does not provide it. The only information released would be the hostname/ip, which is solved by point 2...

      2) I can't remember which ircd does it now (one of the dalnet/undernet ircd's?), but there is a hostname cloaking feature, which removes the last 2 parts of a persons ip, or the first part of their hostname, while leaving enough information to determine what ISP a person is using (useful for legitimate reasons, such as finding out what country a person is connecting from without needing to ask), it prevents script kiddies from obtaining enough information to DoS a user. However it is still possible (even with any ip address blocking) to determine a users address by using netstat on a shell. (This has been done an servers where public shell access is given on the same machine as the ircd)

      The problems not solved by those two methods are firstly, no encrypted communications can be made.. anything sensitive could be sniffed, even over a DCC connection (the paranoid types, like me, who wave hi to echelon and its ilk during most sensitive 'private' irc chats). To solve this, client side scripts could be used to encrypt DCC communications, no new server needed.

      The other problem is lag/netsplits. For some purposes (talking to a small group of friends), this could be solved by using a single-server 'network' (no netsplits) and no server to server lag.

      Most of these solutions require setting up your own irc server, but this isnt too hard to do and is no less hassle than moving to a completely new, incompatible system.
      • However it is still possible (even with any ip address blocking) to determine a users address by using netstat on a shell.

        With some form of "hostmasking" scheme, this is only possible if you can get the person to open a direct connection to yourself (e.g. by getting them into a DCC CHAT/SEND situation). So that is a question of user education.

        Hostmasking as a security method has other more serious problems which I would actually love to discuss (as I am trying to implement this in a non-sucky way) but I fear that for this thread that'd be off-topic. Chat to me if you care, you can find me here [blitzed.org].

        The other problem is lag/netsplits.

        What many people seem to ignore is that multiple servers are there to solve Internet connectivity issues, not to make them worse -- the theory being that a set of servers housed in large organisations under professional hosting conditions are more reliable than the path between any two domestic internet users.

        If your network of choice has servers that split off all the time then those servers should not be there and are likely being used as penis extension tools by people running them off their own @home cable modem (when their mom doesn't need to reboot into win98 to use Word).

        Consider that if your chosen network has 5 servers and one dies, your users can go to another server and resume conversation with the same people. If your network has one server and that dies, well, you work it out. In short, reducing the network down to one good server is only the answer when the other servers are lame.
        • The netsplit problem could be solved, imho, by using a robust form of message passing, something like usenet, with message IDs.

          If one netlink dies, a server simply contacts another server and passes messages that way. It sends all messages it didn't receive ACKs for. If those messages did get through, they won't be duplicated because when a host recognizes duplicate message IDs, it junks them.

          This would also allow a host that completely dropped out of the system to queue up message, so that a momentary outage didn't lose any data.

          I'm interested in this too, but I can't IRC from behind my work firewall. Email me if you wish to talk about it, I'd be interested in talking to someone else with ideas about the system.

    • I.E. bubbles is your nick?

      In that case, /me has a problem...my nick is IE.
    • Being able to see other people's IP's is probably the biggest flaw of IRC. Makes fscking with that guy who just kicked you off your favorite channel that much easier.

      The only issue I can see, is how would DCC Chat establish a connection then? If you make it depend on the server, then you could still trivially get the IP address by faking a DCC initiation. I guess the server would have to stand in the middle and only hand out the IP to each end after each end agreed to the communication. Major change in the protocol.

      • Re:IRC can be fixed easily. (Score:1, Informative)

        by Anonymous Coward
        Nope, the way the DCC protocol works, you send a normal CTCP message to the user you want to connect to yourself. In that message you send the IP address and port you want the user to connect to. So the server still doesn't need to pass out address info, it's just as if you messaged somebody telling them your IP address yourself.
      • No change in protocol required. With the existing protocol, if A wants to dcc to B, it sends a ctcp dcc chat through the server containing an ip and a port to connect to. If B accepts, B's client connects to the ip and port that A provided. If B doesn't accept, no packet is sent and no address is revealed.

        All you have to do is remember to turn DCC autoget off.
      • If you set up a network so you had to log in, and you couldn't get other peoples IP's until they gave them to you, you know what you'd have?

        AIM.

        Only decentralized and open source. IRC is the original instant message client, the main problem is its annoying tendancy to give people your IP address. If it didn't do that it would work very well as the back end for an AIM workalike. Scalability and reliablity improvments would be nice, but not necessary.

    • that only fixes the little problems (Score:1, Insightful)

      by Anonymous Coward
      Most of the big problems with IRC are caused by users feuding over channels. However, nowadays they rarely attack each other directly. Instead, they load up their list of haXX0rd servers and proceed to flood the irc server or its upstream provider with a horrendous amount of traffic.

      It doesn't matter how good your security is on the irc network itself. If someone is able to saturate your bandwidth there's not a whole lot you can do about it.

      There are only two things you can really do. One, is to get the rest of the Internet more secure, and better able to track the initiators of such attacks. Good luck; people have been trying for years.

      The second thing is to take away the adversarial nature of IRC. If users have no power over each other, then there is no incentive to attack the servers. Of course this means you either need a lot of oper intervention, or you don't have much choice over who can join in on your conversation.

      The best solution probably lies with a combination of the two.
  • Nothing of mine is encrypted, What good is encyption when only 1 side uses it? I cant get my mother to use PGP and I have too many OS's to use an encrypted filesystem...

    Just thinking about why you would want to encrypt your IRC session. Some jokes that could be taken as fact.

    [bob] If you stopped hanging around schools, maybe you could get a date your own age! (-;

    Bob must be a pedophile!

    [bob] I need a copy of win95, anyone got cab3?

    Bob must be a software pirate!

    [bob] I just wrote a dvd player in perl using ac3dec and DeCSS! I can now watch my dvds on Athena OS!

    Bob ends up in court for breaking the DMCA

    [bob] Whoa, CmdrTaco just wants to DCC chat me!

    Bob was hanging out in slashnet #PenguinLove again...

    • Hmm, but isn't this just a slight modification of the statement, "The only people who would ever want strong encryption are criminals!" ?
      • I watching a show with the wife on the women's network. (-; The show was about this mom who was accused of child pornography because there was a picture of her kid naked jumping on a bed, and a daughter touching a pregnant women's stomach. The judge (and the end of the tv movie) finally threw the case out, as no merit. But 1 person in power almost ruined the mothers life, took away her kids, and made her goto court to prove she was innocent. It was also based on a True Story(tm)...

        We live in a society where your guilty till proven innocent. And anything you say, can and will be used against you... The Law enforcement agencies will come in, kill your family and friends before they have any proof of any crimes. An anonymous tip is all it takes for someone's life to be ruined, or ended... (I don't need to point out cases, there are hundreds or people each year that die at the hands of the police...)

        Its not all conspiracy theories, its people who think they know what is the best for Joe Q. Public. We must down size government and let people live their lives without repercussions of the moral majority. Until then, we have to protect ourselves from the jack booted thugs. (Sorry to sound like a paraphrase...)

        ---
        Stoop and you'll be stepped on; stand tall and you'll be shot at. - Carlos A. Urbizo

  • Is AVS (adult verification system). :-)

    Yeah, but not all IRC kids are packet kiddies. Then again...if I didn't discover IRC in my preteen years I might be alive today.
  • The problem I see with this is that in order to be effective, it must be widely accepted as the de facto standard. A friend of mine on a small-ish network is actually working on an app that, when hooked into by a script-enabled client, allows for encrypted irc over normal protocol servers. Very cool, but could open a whole can of worms of security issues in itself.

  • I don't expect secure IRC (Score:3, Funny)

    by wirefarm ( 18470 ) <jim@@@mmdc...net> on Thursday August 09, 2001 @08:35AM (#2128865) Homepage
    And I don't expect pure water in gutters, either.
    Yet both seem to serve a purpose, don't they?

    Cheers,
    Jim in Tokyo
  • This is ridicolous. If the reason for all this is the skript-kiddos thumping away at the big irc nets, then I say this is not the right means to deal with the problem. IRC doesn't need encryption and all that crap, except perhaps of DCC chats. It's a total waste of computing power. And it will make my IRC client obsolete :P Tunnel IRC connections through SSH if it's that goddamn important ;)

    An improvement in the way the servers communicate, resulting in better stability and availability, would however be very welcome.. It's rather ridicolous that networks like openprojects are so incredibly unstable - and afaik that's not even due to attacks, but simply that people don't understand one basic rule: "If it's not broken, don't fix it!"
    br
    • ssh tunneling will only help you encrypt between your client and the nearest server, but still goes over the unencrypted net.. the SILC website touches on that. it really depends on where the security threat is. but what's more likely, someone's going to be snooping at your office on the connection between the irc client and the ISP/backbone provider, or someone snooping on the big backbone between the irc servers.. not too likely on the latter. ssh wrapping would help by that token, but not totally. as for security on irc, irc is admittedly overpopulated with script kiddies, but there are a minority of people who use it for legitimate chatter and a small percentage more who would use it if they felt it was secure. I'd probably talk about my personal issues with my friends if i knew I had a secure channel. stuff I don't want just floating around to any ircop on a hackedup server. security is a legitimate concern. don't discount it so quickly.
    • I totally agree. The reason people need more and more security is the little script kiddie who happens to have a copy of netsphere or who's gotten his hands on some IRC utils. IRC bots could be the answer - bots that hunt script kiddies down and ban them. It'd cut down on all the research that goes into making IRC more secure too.

      • Re:IRC doesn't need security.. (Score:5, Insightful)

        by krokodil ( 110356 ) on Thursday August 09, 2001 @08:33AM (#2121007) Homepage
        This is not a reason you need more security. Let me give you an
        example: I hang on IRC to chat with friends. I usually sit there in
        passive mode and if somebody wants to talk to me, they could. Kind of
        instant messaging, but using more popular and accessible
        media. Sometimes my colleagues from across the ocean stop by and want
        to discuss some business related issues. Main problem is our
        conversation (if it is not DCC, which in most case does not work
        because of firewalls) could be observed by any IRC server
        operator. There are dozen servers on network, some administrated by more
        than one person. You could not assure integrity of all these people.

        Proposed system will solve this problem, since all communication will
        be encrypted using public keys of participants and channel keys. So
        several people can chat on channel in confidence that nobody is
        snooping their discussion.
        • You overlook the fact that server operators can join any channel - private or not.

          Anytime you have a server-based protocol, you'll have people who will not be willing to change to a protocol they can't snoop on.

          Major changes to IRC are going to be a hard sell. A very hard sell. And I just don't see it happening.
          • The solution to the snooping problem is client based encryption. Not the silly replacement encryption that was popular not long ago, but real PGP or something. There is no reason that I can see that some sort of encryption algo couldn't be placed in a client and used.

            Granted it will be as annoying as all hell to those people with out the special clients but the people with encryption will flock together just like the silly people with that comic chat heh :)

        • So run your own server. Then again, your friends would be paranoid of you then, huh?

          I got tired of everything that was going on on EFNet a couple of years ago, and have been running my own server for mountainbikers ever since. It's great! Full control, and only people with the same interests pop in.

          I disabled ident lookups, so even when people are at work behind firewalls, they can still use my server.

          • OK. Let us assume I am interested in mountain biking
            and will hang on your server. But I also interested in motorcycling, so I hang on another one. Since I also
            like Linux, should I also hang on Linux server? Running 3-4 IRC cliens under 'screen' may work but will be extrimely uncomfortable.

            • Not necessarily. There are several irc clients that allow you to attack windows to specific servers. I use BitchX and the /window server commands allows me to log into efnet with a window, while I idle ina channel on another. Each server has a window.

              If you run windows you can always use something like xirc that has similar features.

              dewke
            • Decent IRC clients allow you to connect to several different servers at the same time. And yes there are decent textmode clients also like for example irssi [irssi.org] which seems to also have plugin for this SILC stuff.
    • To quote a comment from the article last year:
      Friend of mine works at (large computer manufacturing company). They have a non-official irc channel, sort of an e-WaterCooler...
      Anyway, internal MIS dept. found out about it and started sniffing the network, and logged EVERYTHING that was said in the channel over a three week period. Talk of stupid bosses, who was screwing who, drug taking at weekend parties, the works.
      Upshot: 6 people fired, 3 more severely reprimanded.
      So thats just one reason I can think for encripting IRC communications.Whats the problem with having an extra layer of security?
    • As discussed recently on bugtraq. . .

      The IRC protocol is a badly designed protocol. Permitting DCC connections is a security risk to your computer or network, because DCC is even stupider than active ftp.

      It *is* broken and *should* be fixed.
    • Perhaps you haven't tried to log on any IRC network lately. It's a frigge warzone with servers going down 5-10 times a *day* because some 10 year old lost ops in a channel. It was never meant to be abused and as such, is totally broken.
      • Any IRC Network? I think you'll find it is only the larger networks such as Efnet, IRCNet, Dalnet, Undernet etc. that are currently under kiddie attacks. There are plenty of other networks out there that do not have any of these problems.

        Most people who use IRC regularly will stick to a few channels 99% of the time. It isn't a huge task to move a channel onto a new network if everyone who uses the channel is aware of the move. Something as simple as placing the details in the topic is usually all that is needed. The channel I've used for the past three years has moved twice now, and even changed names once.

        IRC as a protocol does has flaws when you scale it past a dozen servers or so, but that doesn't mean IRC is a wasteland. Smaller networks are better, generally, as they're run by admins and opers who give a damn.

  • If we want this, or some other form of secure-IRC style communication, it's going to require clients that can speak both protocols.

    If the client can speak both (IRC and whatever Secure IRC), eventually a seamless transition becomes possible. Once the new clients have sufficiently diffused (say, if they came out now a year or two), servers could switch to the new protocol with out most of the users even noticing (Although it would probably be a good idea to show a little icon saying weather the connection is secure or not).

    Any way, the advantages of a secure protocol are obvious, and here you have my thoughts on how to get it into use. Of course, this requires IRC clients to actaully implement the second protocol. What do the rest of you think of this idea?

    • Bilingual clients would be confusing. But your idea does address the problem of transition or adoption, which is problematic for dozens of popular insecure programs or protocols or OS's vs. secure ones. Telnet is still widely used, so are insecure unices and many insecure windows machines aren't even patched. More people give lipservice to security than implement it, and there are often significant impediments to impementation even if the desire is there (i.e. management wants desktops usable by new employees w/o training or technical complexity is greater than technical ability of security conscious user). This product is just another in a long stream of products and services. People don't want security, as MS correctly estimated, they want features. Security isn't something you "have"- if it's secure it just does what the non-secure product does- and often worse- slower, more logins, expires, etc. Therefore to compete with IRC it would need a comprable feature base and or more features or equal or easier of use, i.e. it has to be a *better* user experience along with being secure.
  • Ok, I'm not that savvy on compiling Unix stuff. I downloaded it and ran ./configure but it says it can't determine the type of host. What do I need to enter as the host type to get it to compile in OS X?

  • SIC (Score:3, Funny)

    by csbruce ( 39509 ) on Thursday August 09, 2001 @03:28PM (#2140438)
    secure alternative to IRC; the Secure Internet Live Conferencing (SILC)

    They should have called it just Secure Internet Conferencing (SIC). This term would provide connotations about the content and would help to excuse some of the spelling errors.
  • Even though script kiddies wanna be crackers would have a go at SILC ,why should we worry ? There is a SILC server package.This allows one to have a private server ,and have private conversations ! Yes if you use a public server there is a chance some kiddo will try to crack his way in, but on a private server for real work and conferencing this is not only promising but also convenient.Ill have my server and only the people i need to conference with will have the server name. So private server add to it encryption .That's ok in my book for doing conferencing..which is it's main goal if i read right (Secure Internet Live Conferencing ) G'day
  • You know, for all of it's frustrations and hazards, i hope IRC persists in it's current form forever. It's the last real "lawless" corner of the web. I mentally relate it to the saloons of the old west, where a great story or a dangerous barfight are only moments away. Of course, it's being flooded with more and more luddites nowadays (think of the old west saloon being flooded with tourists from New York), but IRC to me represents a sort of living communal electronic nostalgia, one i'd hate to see phased out completely.
    • i totally agree. i've been on undernet since i was a kid (like, 8 years almost), in mostly the same channels for years. call me nostalgic, but i feel as if i "grew up" on there with a few people i've (mostly) never meant. i hope i can still go on an irc network when i'm 60.

      irc can definitely be the most "personal" protocol
  • ...will it have pr0n and mp3?
    • this comment was marked troll, but like everyone doesn't use the net for porn or mp3 or other file transfer? This is actually a pretty good index of whether people would want it. If it was secure, *and* it acted as an excellent file transfer client, it would be a pretty winning product.

  • Securing an open system would be hard (Score:3, Insightful)

    by hardaker ( 32597 ) on Thursday August 09, 2001 @08:18AM (#2151041) Homepage
    In other words, trying to secure IRC would be difficult to do successfully. Most of the problems associated with IRC come from it's allowed annonymous access by many servers. IE, you don't need an account with a password to join. This gives annonymous access and hence can be nice if you have debatable things to say that you don't want others to see. However, it also allows for "flashing" DoS and other IRC related fun. The proper way to secure IRC against abuse would to be only allow servers that check authentication and make people accountable. It is possible to do this, however, without sacrificing annonimity if you trust the servers you're using (ie, they authenticate you for accountability purposes promising they won't give out who you are without a court order). This will likely not prove to be popular among people who want to be annonymous further than that (like Flashers, of course).
    • Hey pal? READ THE ARTICLE. READ ABOUT SILC.

      From the FAQ on the SILC website...

      Under "What is SILC?":
      Biggest similarity between SILC and IRC is that they both provide conferencing services and that SILC has almost same commands as IRC. Other than that they are nothing alike.

      Under "How much SILC Protocol is based on IRC?":
      SILC is not based on IRC. The client superficially resembles IRC client but everything that happens under the hood is nothing alike IRC. SILC could *never* support IRC because the entire network toppology is different (hopefully more scalable and powerful). So no, SILC protocol (client or server) is not based on IRC. Instead, We've taken good things from IRC and left all the bad things behind and not even tried to burden the SILC with the IRCs problems that will burden IRC and future IRC projects till the end. SILC client resembles IRC client because it is easier for new users to start using SILC when they already know all the commands.

    • -Wackysootroom- slaps hardaker with a large trout
    • That's got nothing whatsoever to do with this topic. We're talking about encrypting communications, and you're talking about stopping abuse. Score:4 indeed. Moderators don't read the articles either.
    • > it's allowed annonymous access by many servers.

      IRC does not allow anonymous server connections!
      You need to have C/N lines in server cfg to be allowed
      to connect.

      But allows anonymous cliens. Not completely anonymous -
      most IRC servers try to use IDENT protocol
      to check client identity, but this could be
      easily faked.
      • I don't understand why some networks still insist on getting an ident reply before letting you connect. I mean really, that just means I need to map a port on ICS to allow mIRC to send back a random fake ident response.

        Whats the point?
        • I don't understand why some networks still insist on getting an ident reply before letting you connect. I mean really, that just means I need to map a port on ICS to allow mIRC to send back a random fake ident response.

          Most servers use it to verify your IP..nobody uses it for username anymore

        • Not so long ago, kiddies commonly bounced through misconfigured proxies onto irc in order to hide their true hostname, avoid accountability, etc.

          Most proxies do not provide ident service. Therefore, the easiest way to block these people was to block non-ident clients.

          The other alternative is to scan hosts as they come in for open proxies, but you can imagine the floods of "your server portscanned me" emails. It's also yet another extra program to be running on the server, with all the bugs inherent in that.

          This is a pain for people legitimately using proxies, but for the rest of us it's a minor nuisance and a major win.
    • The members of the chat room I am in use a
      crypto plug in called rcforge. We use the CS2
      protocol, and it a) protects are convos, and b)
      keeps the strays to a minimum. And its very easy
      to switch back and forth between clearn and coded
      text.
  • Does IRC hold promite as a secure communication mechanism? Seems to me it's major flaw is that it's server based, whereas there are Instant Messaging systems which facilitate Live Chat without the need for server intervention (for the chat function) which reduces the liklihood of the conversation being recorded/stored by some one who is not a party to the chat. What we really need is SSL integration with Instant Messaging systems (rather than just PGP as ICQ has), since Instant messaging has a far greater userbase than IRC, which is still dominated by the Geek set. The non-technical public has latched onto IM as their chief means of realtime online text chat. br>
    --CTH

  • Won't Work (Score:4, Insightful)

    by audibility ( 136433 ) on Thursday August 09, 2001 @08:24AM (#2151194) Homepage
    The big-sell factor for IRC at the moment is its age. It's been around forever, and there's enough knowledge of it and how it works / software / literature / networks etc etc out there to form a user base.

    It'd be far too hard to implement this system attractively wide scale, simply due to the fact that IRC has been losing usefulness (in it's intended form) for quite a while now.

    There's no real demand for such a system. If people care who's listening they use encrypted email / private messaging software - they may themselves not be totally secure but you've got a better chance if you talk to 1 person than a room of 78.

    Current IRC users don't give a shit who listens. Just the way it is.
    • Though one of the reasons IRC (imo) ,as far as *chat* is concerned, has been declining in popularity is due to the general chaos and warring that goes on. Also with the design is the concept of channel ownership and privledge levels. The encryption is an added bonus/mechanism.

    • You're basically correct, but you have it reversed (Score:5, Interesting)

      by FallLine ( 12211 ) on Thursday August 09, 2001 @08:50AM (#2151401)
      People continue to use IRC, by and large, as a method of open communication because of its particular user base: friends, acquaintance, partners, groups, and like-minded individuals use it.

      It's basically a network effect, much like that which allows MS to continue to produce relatively mediocre products. In other words, you won't use method XXX, because your friends won't be there. Your friends won't because you (and others) won't be there. Unless a substantial portion of the given social groups actually agrees to coordinate a movement, the entrenched users will stay and put up with the crap (to a point).

      The bottom line is that IRC, in and of itself, has very little going for it as an open forum: it's harder to learn and use; it's laggy; its service is poor; it's insecure; and so on. It's continuing use owes largely to its users, not to the technology itself.

      Public IRC should be extinct by all rights. That said, the fact that is easy to setup a server and free, means that it still has a role for private/commericial uses.
      • IRC is open. Nobody can hijack the standard, even though MS tried to extend it without much success.
      • > The bottom line is that IRC, in and of itself, has very little going for it as an open forum: it's harder to learn and use; it's laggy; its service is poor

        That only matters when there are people around the world on the same channel. But I don't think any system of that scale could manage much better. The internet is lagged and slow these days. Sometimes it takes ages to load web pages overseas (that is, the US) because the network at some point is totally lagged there.

        But when all the people on a channel are using the same or nearby servers, IRC usually works very well. That happens be the case with all the channels I'm on. Everyone uses the university IRC server located just a couple of hundred metres from here.

  • [- ]Secure key exchange and authentication protocol. SILC Key Exchange (SKE) protocol provides key material used in the SILC sessions in secure manner. The protocol is immune for example to man-in-the-middle attacks and is based on the Diffie-Hellman key exchange algorithm.

    I wonder how they made Diffie-Hellman KEA safe from a man-in-the-middle attack, as I understand it this is extremely difficult and D-H doesn't help you a bit.

  • If you're talking about an IRC that's been modified to get rid of some of the exploits, try IRCX.

    If you're talking about a chat system where all communications are encrypted (though the crypto is suspect), try Filetopia.
  • Q: Does SILC support file transfer? A: Not yet. This is a feature that will be added to the SILC protocol. The exact file transfer protocol is undefined.
    Q: How secure SILC really is? A: A good question which I don't have an answer for.

    Okay, so let's go down a checklist: 1) No file transfer yet, and when it comes, we don't know what the protocol will be. You know, IRC is really more than just a chat network, Files are also important. When you want to find a hard-to-find mp3, where do you turn? IRC. If you want the latest Southpark episode because you forgot to tape it, where do you turn? IRC. If you want to fine fansubbed anime, or test out a series before you spend money on a DVD, where are there tons of fservers dedicated to anime? IRC. If you're looking for almost any type of file, where to turn? IRC. SILC, even if it does get a protocol (which allows fserves) couldn't get the sheer volume of stuff that IRC has. SILC will never replace IRC, for that reason alone.
    2) Wow, it's more secure, but they aren't really sure how secure it is. It might as well be the latest security feature out of Microsoft, for all that they can tell us. They mention stuff, but they don't actually answer the question.

    Well, these two, for me, are enough to persuade me that I'm not uninstalling mIRC, and not going to be d/ling SILC any time soon. Besides, IRC is great because of the variety with the people, does SILC have that? Nah. I'm sticking with my beloved IRC, thankyouverymuch.

    • Q: How secure SILC really is? A: A good question which I don't have an answer for.

      I'm answering this one first. Or more than that - can YOU tell me exactly how secure RSA as an algorithm is? Or AES (Rijndael)? SSL as a protocol? The PGP specification?

      None of these have absolute and accurately measurable "amount" of security. The algorithms are open, as are the protocol specifications. We only know that they haven't yet been publicly broken. We use them, and we trust them.

      SILC is by no means a silver bullet and it's not meant as such. Personally I think it's one huge step into the right direction. One, it adds to the generally small amount of encrypted traffic which is always good. Two, nobody owns a nick in SILC network so the ever increasing nick wars as seen in IRC are not going to be a problem. Three, people are touting about not using telnet when we have SSH. It didn't happen overnight.

      No, I don't think SILC is ever going to replace IRC, in the same way that SSH has not replaced telnet. What we need is more clients, more users and a lot more testing and good ideas as to how SILC should be developed. It's not a ready product but it's definetely quite stable - and because the UI is almost exactly like IRC, those that wish to give it a try should feel quite at home.

      The SILC protocol appears quite solid and the person who designed it, has had it brewing for ages. No, he's not an established crypto authority like Zimmerman or Biham. But he works in this field and as such, has a pretty good insight. The protocol is still under developement, as you have noticed. The chat part is quite finished but file transfer is not yet there. What we need is a set of really good ideas and a streamlined protocol for file transfer. You have a very good point about that - but how long did it take for IRC to have DCC capability? I'm pretty confident it didn't have it at the very beginning. Don't bash SILC just because it's still an infant and trying to grow.

      You have absolute rights to your opinion, and I respect that. I just used mine.

  • IRC may not be the greatest protocol ever, but it work, and there is an irc for basically every platform. I can go and download 3 different irc clients for my palm pilot right now, i cant download an silc client for it.

    Also, i dont see that this solves any problems with irc that havent already been solved. There has been irc over ssl for a while, it is no to widly used, but there are places that use it. There is authentication via nickserv. One of the ircds has hostname cloacking so people cant get your hostname. And as far as being scaleable, irc is very scaleable, a single server can easily handle 30,000 connections, and it is not to difficult to make a net of 20 server. Using routing servers makes this even more scalable.

  • I'm sceptic (Score:5, Interesting)

    by borud ( 127730 ) on Thursday August 09, 2001 @05:07PM (#2152626) Homepage
    I started reading the "SILC Protocol White Paper" [silcnet.org] and I have to admit that it I didn't make it further than a few pages before I lost interest. Mainly because of the language and what it told me.

    I am not talking about the embarrasing mutilation of the english language, but the fact that you can tell from the wording that the person who wrote it is neither a cryptographer by profession or someone who seems to have digested any significant amount of litterature related to cryptography or security in general. If you've read a good deal of scientific papers on cryptography and related areas, perhaps digested a couple of books you can spot this quickly. People who understand cryptography express themselves quite differently. They strive to be precise and they are much more reluctant to call anything safe without at the same time either giving some measure of what they mean by "safe" or pointing out limiting factors. And God forbid: they'd never point their finger at a complex system and say that it was provably safe unless they could actually prove it.

    I doubt you'll ever se any formal proof that SILC is secure.

    I know most people would say "so what?". A lot of people would even say "well, you don't need a Ph.D to write a crypto app" -- and they would be right. you don't. however you still have to know a bit about cryptography and a LOT about how you avoid basing conclusions on assumptions.

    (Just ask Bruce Schneier if his book "Applied Cryptography" [counterpane.com] suddenly lead to more quality crypto software being written. Tip: it didn't. It lead to more inept people writing even more bad crypto software). But you do need to understand what you are doing to make any kind of valid statement about what one should expect.

    In any case, my point is that it takes a certain kind of mindset to design and implement anything having to do with security. The aforementioned white paper was apparently written by someone who understands some of the mechanics involved, but who doesn't seem to have absorbed any of the intellectual discipline good cryptographers convey in their writings.

    I was thinking about downloading the thing and possibly install it, but if the white paper is that naive, what is the actual system going to be like? Probably not worth the bother from a security point of view, although one might actually learn other things from such a system (for instance their approach to message routing etc. I don't know I never got that far once it became obvious to me that this was the wrong place to look for a *secure* system)

    So why am I writing this? To slam SILC?

    Definitively not.

    I'm writing it because most people are too ignorant, or to arrogant about their ignorance, to realize that they probably wouldn't be able to tell a more secure system from a less secure system. Also, because I think it is important that people try to make an effort to understand what type of security something provides -- ie. exactly what does the system prevent and what doesn't it prevent. I'd like people to *think* instead of choosing their security solutions the way most consumers choose toothpaste.

    • It would be fairer of you to use your self-proclaimed greater knowledge of cryptography to find an exploit that exposes the ignorance of SILC's author.

      As things stand, I am meta-skeptical.

      • Re:I'm metasceptic (Score:2, Insightful)

        by borud ( 127730 )
        Pay attention; I did not proclaim that I had greater knowledge of cryptography than the author. What I said was that the way in which the author talks about SILC suggests to me that the author is not experienced in designing or even describing security systems. People who design security systems are usually more precise in their wording and more reluctant to make assumptions or vague statements.

        As I also mentioned, I do not doubt that the author knows the "mechanics" of cryptography (ie. how things work in general, the basic underlying theory and how available libraries etc work). But knowing the mechanics of cryptography isn't even half of what is needed to create a security product. On the contrary, it might be dangerous because it lulls you into the false assumption that you actually know what you are doing.

        What I do doubt is that the author has the scientific discipline to be self-aware in terms of understanding what types of weaknesses a design can have and how these should be weighted in terms of how they do or do not contribute to "security".

        Since you drag me into the discussion I'd like to make a few comments:

        First off, you do not have to be an opera singer to point out that the prima donna can't hit half the notes she is reaching for. My observation can be verified by merely analyzing how practitioners of cryptography, mathematics or even security theorists express themselves. In particular you will find that when these people publish papers or describe their work they will strive to be precise and careful -- not vague and self-confident.

        Second, I do not proclaim that I have greater knowledge of cryptography than the author. I might have and then again I might not. It isn't really interesting. What I think I do know more about is what kind of mindset you need to have when approaching security solutions. Again, if this applies to me or not, or to what degree, is not really important. The only remotely relevant aspect is that I've done enough work with security solutions to be able to _recognize_ handwaving.

        (Ideally most people should be able to recognize someone having an under par grasp on a given subject matter, but unfortunately many people neither posess the academic discipline to evaluate what they see in a cool, objective way nor do they have the inclination to understand basic scientific principles you need to follow in order to arrive at valid conclusions.
        This observation can trivially be made on Slashdot: how many people exhibit an almost religously strong preference for a particular system while at the same time exhibiting narrow or lacking knowledge of a particular field (eg. OSes, languages) at the same time? I'd say most users. Well, most of the vocal ones anyway).

        Third, you reveal a compelling lack of comprehension as to what a useful contribution from me or someone else would be in this case. Your preoccupation with "finding an exploit" reveals a naive assumption that "it is just a matter of finding and plugging the holes".

        The most important problem with the SILC white paper is that it implies that the author did not start by asking fundamental questions and find answers to them. Nor does it reflect an understanding of the importance of doing so when designing a security system. If he had, he would have started by stating the problem in a precise manner and presented a plan for solving the problem.

        What he does in the whitepaper is to make general statements about how secure the system is, with contradictory notions sprinkled throughout.

        For instance he says that the user must trust the server. Then he says the user can't really trust the server. Which is it? If the author can't even clarify what parts of the system you need to trust and what the criteria for trusting them are within the first few pages then what is this guy doing designing a security system? Because apparently he has no idea what he is doing.

        I say that because I have found myself in exactly that situation many times; thinking that I know what I am doing because it didn't occur to me that I needed to question my assumptions.

        If you are at least able to discover that you don't you've accomplished a lot. I am sorry to say though: not many people are.

        And you do not need to hold a Ph.D in mathematics to understand that something is VERY wrong here.

        I have spent a lot of time trying to understand security systems. It is hard work and I still do not consider myself a guru (although I do know that I probably know a hell of a lot more about what sort of discipline you must exercise when designing security systems than most so-called "professionals"). Far from it.

        But: I am very _aware_ of my limitations and I keep asking myself if I am basing something on assumptions or if I actually know something. I'd be appropriately reluctant to stick my neck by making statements I would be unable to back up when designing a crypto app.

  • Gale (Score:2, Funny)

    by sjh ( 29820 )
    Check out gale:
    http://www.gale.org

    for a secure, open source messaging system...
  • Jabber [jabber.org] clients offer GPG encryption of chats and presence declarations. Open specs and all provided in extra-crunchy streaming xml!
  • For instance, look at UnrealIRCD. You can compile it with SSL support, and the clients that support it (I know Xchat does, not sure about others) can connect and Comunicate via SSL based connections to the server. Sure... Maybe the admin of the server can sniff your converstation, but no one else on the internet can.
    Its just as secure as this SILC, but still has the stability and popularity of IRC that has been developed longer than webservers themselves (IIRC)
    (Unrealircd, is at www.unrealircd.com)

Slashdot Top Deals

Brain off-line, please wait.

Close