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.
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.
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.
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.
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?".
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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!
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
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.
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.
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
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.
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
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...
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.
Jabber clients offer GPG encryption of chats and presence declarations. Open specs and all provided in extra-crunchy streaming xml!