Slashdot Mirror
Secure IRC?
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.
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.
Does it support ip-masquarading firewalls? Looks like the forwarding feature redirects the sender to a different machine. If the new receiving machine has a private IP, you're hosed.
Just append "powerpc" to your ./configure line
>80 column hard wrapped e-mail is not a sign of intelligent
>life
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.
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.
generic
Most servers use it to verify your IP..nobody uses it for username anymore
//m
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.
.ph0x
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.
---
ps -aux | grep mind
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.
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.
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 :)
until (succeed) try { again(); }
IRC is open. Nobody can hijack the standard, even though MS tried to extend it without much success.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
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.
USENET could benefit from a Slashdot style moderation system.
DCC chat is direct client to client chat, so there's no server intervention there.
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.
You've got mail. Pattern baldness. - Crow
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.
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.
You just described the fundamental problem of public key cryptography; you still need to authenticate the public keys and/or certificates. Well, so it is, what can you do about it? The same thing is any other system (SSL, IPSEC, SSH etc.) which uses public keys or certificates. You must always authenticate the identity.
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?".
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.
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.
Simple solution:
;)
ssh to a box _outside_ work, and irc in. After that there's no way that a) they can sniff you, or b) they can prove that you're on 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.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.
I thought UnrealIRCD already had ssl connections, and XChat 1.6.4+ have an option to connect in ssl mode.
this is great and all.. but i doubt many hard core ircers are going to give up dalnet and efnet in order to be secure. is there any information i missed on how long that would take? the popularity of this program isnt going to be widespread until theres support for most of the major communities.
yes, script kiddiez are l4m3 and getting flooded or bomed or anything else from your favorite server is annoying, but its not bad enough to make me leave my 7 year home of #phreak
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?
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
At last the script kiddies can curse and trade illegal software with eachother over a completely secure network. It's about damn time.
Stupidity never felt so good.
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.
For your security, this post has been encrypted with ROT-13, twice.
Why is it when somebody releases information about a project they're undertaking to give away for free for the benefit of everyone there always have to be some assholes hopping in, not having bothered to read the damn FAQ or anything (which explains why not to just SSH-tunnel IRC) to bitch and moan? Why is so important to your ego to tear down productive people? Probably because if you based your ego on what you yourself have created, you'd have nothing.
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.
Do not look at laser with remaining good eye.
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.
-- "If you need to shoot, shoot. Don't talk" -Tuco
> 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.
Very well. What about reading the actual protocol specification that cannot be considered "press material" as much as white papers can be? After all white papers do not define anything, they just describe it so that everybody understands what it is about. Your comment in general is very good but do you draw conculsions about any given protocol's security considerations by reading mere press material?
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.
JUST PGP? PGP is so much more insecure than SSL? Is that why the FBI had to put a keylogger on the Mob keyboard to get past it?
m00.
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.
About a month ago, you could bang about 512 A's into the silc TCP port and overflow it. Is this still the case?
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
Oderint dum metuant
-Wackysootroom- slaps hardaker with a large trout
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...
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.
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.
Thanks for the point back, I would have used "underrated" rather than "informative" though.
Offtopic? Looks like a moderator has no sense of humour... Bah... Burn karma, burn...
One shall speak only if what one has to say is more beautiful than silence
Um, hallo ? Anybody who has played around with ircii properly will have noticed that it has built in support for encrypted channel/conversations activated by a key/password (client to client). Normal irc clients will just see the encrypted conversations as a bunch of garbage. It's entirely feasible for popular irc clients (mIRC, BitchX, xchat, etc) to incoporate encryption on a basic level without requiring corresponding support on the ircds.
...girc and kirc sound ok but gsilc and ksilc - NEVER!!!
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.
Just because a few of us can read write and do a little math, doesn't mean we deserve to conquer the universe
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.
And I don't expect pure water in gutters, either.
Yet both seem to serve a purpose, don't they?
Cheers,
Jim in Tokyo
-- My Weblog.
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
Love over Gold.
Hey, moderating bitch, MS did extend IRC, but it didn't take off. Ever hear of Microsoft Comic Chat? It's IRC. Fucknuts.
You obviously havent used Direct Connect.
Licq have support for SSL.. www.licq.org
hi, afair from last time I looked at silc site, server is trusted by all users, i.e. operators are still able to read your stuff. there are other issues with silc, like if you wanna authenicate someone who wants to talk to you you need to know either their or their CA public key beforehands... evidently that doesn't help you anywhere... moreover anyone can still have multiple identities which is uhm, uavoidable?
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.
-- "If you need to shoot, shoot. Don't talk" -Tuco
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.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
> 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.
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?
The internet will continue to be used for nonessential purposes. Get over your smug judgements and self elevation. The thin air up there is making you loopy.
Newsflash! What YOU think is an important use of the net is worth its weight in cat shit.
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
So:
(1) join the project and help make it more stable or
(2) don't use it and shut the fuck up.
Gawd, what a l0s3r.
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.
Especially Question 2.3. SILC goes waay beyond just "encrypted IRC".
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?
--- What?
It seems inevitable that old protocol's need some type of overhaul. IrcOp's grow tired of script kiddies security evaision and abusive users lack of respect for the privilage of use. It's one of the main things users seem to forget after all, Irc is not a right. .. ha! Take a look at one of the more well known ones, conferenceroom by webmaster. For only $4,2** dollars, they would be glad to sell you their top leval program, which by design does add various security, and a major security flaw, or excuse me, a back-door. All anyone with knowledge of your software key has to do is type" /oper your-soft-ware-keey webmaster " and they are given complete root access to your server. Passwords, services, agents, anything can be compromised from that point. And as an added bonus, the software does not send any notice, global or otherwise to the administrator or other operators alerting them to this. Nice huh ..?
.. but when your remote and to hung-over to remember your password ...
...
And then you have comercial programs that are available, which by design should give you a different sence of security
---
posting anon sucks
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.
Syllable : It's an Operating System
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.
...will it have pr0n and mp3?
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).
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Looks like Michael is getting afraid of seeing all those "Hey, that is old news, we got that last year already" :)
Come on Michael, stop walking on eggs ;-)
One shall speak only if what one has to say is more beautiful than silence
you think this will stop them skript kiddos who can hack away at it 16 hours a day? And the most frightening thing is they are motivated to do it.
The World's Best Music!
/* * pope1 */
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
--Got Lists? | Top 95 Star Wars Line
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.
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.
Microsoft Comic Chat?
Yes, it's fun for a few minutes if you're drunk or really bored...but loses its appeal shortly after. It's also really annoying because it spams. " (GARBAGE) Text", which is because most of the comic chat users are too dumb/uninformed to turn off the extra information it sends. Leave it to Microsoft to fuck up something that could've been cool. Over. And over. And over...
-HobophobE
Nothing laughs forever.
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.
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.
[- ]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.
.oO Kaa Oo.
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: 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.
There is no such thing as good luck. There is only misfortune and its occasional absence.
A secure IRC system has been around for a while from Webmaster, Inc. Its proprietary sure, but it runs on just about everything. The clients and the servers can both communicate through an SSL connection.
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.
Erik
"You," Bite me.
"Each and every one of you." Bite me.
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.
-- free as in swatantryam - not soujanyam.
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" 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.
Check out gale:
http://www.gale.org
for a secure, open source messaging system...
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.
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.
As things stand, I am meta-skeptical.
Seastead this.
Jabber 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)