Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
News

IRC Improvements 75

SUIDNet writes: "The first ever secure IRC network has opened. All your communications on the SUIDNet are completely encrypted so no one can just sniff the network and watch your conversations. In addition, anyone who connects unencrypted automatically has a "-insecure" appended to their hostname and are banned from all SECURE channels. Check it out for yourself at http://suidnet.org or irc.suidnet.org." We also got a submission about a plan to improve IRC routing, Open Redundant-Link IRCd.
This discussion has been archived. No new comments can be posted.

Secure IRC Network

Comments Filter:
  • by Anonymous Coward

    Anyone else remember BITNET relay chat?

    Back in the late 80s/early 90s our university's lower-level CS courses were all on Waterloo Pascal/ Fortran on IBM mainframes (3033/3090) using the MVS/TSO, and VM/CMS environments. We
    accessed 'em thru a bunch of burnt-in surplus (from some chemical plant) color 3278 terminals -- with the 10 pound all-metal keyboards. Loved that character set though -- very readable.

    These machines had pretty nice "instant messaging" features, and we had available to us all sorts of chatters and frontends.

    I'd connect to Bitnet Relay chat thru (IIRC) TAMVM1, and there'd be numbered channels, those over (I think) 50 were "invisible", I suppose for private groups.

    BITNET was fun -- the fileserv's, the listserv's, a great hypertext'ish navigation system -- you could see who was logged onto mainframes all over the world.

    ugh...then came the september that never ended.
  • by cras ( 91254 )
    Yes, SILC is good :) I've been playing it with a few months now and making my own IRC client (irssi) support it.

    For me the best thing about SILC is not just the security, but that you can still affect it's development and the protocol to create the best IRC replacement you can think of. And I do intend the SILC to replace IRC one day :)

  • > distributed to every person in the channel. or you could pick and choose who to add to your irc keyring.. but now that I think about it, encrypting a message for as many people as you find on a busy irc channel with rsa might take quite a bit of processor power, it was a nice idea tho =P.
  • by drrobin_ ( 131741 ) on Saturday September 30, 2000 @06:24AM (#743311)
    Much as you may not like it, you can't set limits on free speech without it becoming un-free. I've seen a lot of jabbering about kiddie porn in the comments. So what? If some people, for their own reasons, like trading that stuff, who are you to tell them they can't, just because you don't like it?

    What if they said that the picture of your kids at the beach, building a sand castle constituted kiddie porn?

    My point is that you can't draw a fuzzy line in an issue like this. Just saying 'Kiddie Porn Is Bad' won't get you anywhere. Sure, it'll make you look better in your community, because the majority of people will agree with you. But that leaves the door open for too much abuse. Where does porn start? Where does your picture at the beach fit into this?

    A hard line, like "Kiddie Porn is when Nipples Are Showing On Children Under 18" is also ridiculous. Ever seen a Huggies commercial? Would you call it porn? This also leaves room for they people you are trying to stop to maneuver around the law. ("See? She's not showing her nipples!")

    If you support an encrypted IRC network, then great. If you don't support an encrypted IRC network, then great. If you support a specially monitored, only 'nice' channels allowed, Absolutely No Kiddie Porn network, you're in for a tough time. How are you going to regulate it? Are -You- going to do it? Who would come to your network, anyways?

    Comments like 'Encryption makes spreading kiddie porn' easier are pretty silly. Of course it does. Does that mean I shouldn't use encryption? Does that mean there should be a trusted IRCop in every channel, watching for any kiddie porn? Much as it's nice to have morals, whining won't solve your problem.

    PS- If you really want help your kiddie porn crusade, I suggest you contribute to developments in AI. If you accept the idea that people will eventually create a self-aware computer program, you can accept the idea that it will probably be used to monitor internet traffic.

  • I've been involved in the IRC community for the last 10 years or so, both from a user and admin perspective (anyone remember pilot.njin.net on EFnet?). I've come to the following inescapable conclusions:
    • IRCII in its current form is not fault tolerant (single path between any 2 clients, if that path breaks, the entire network splits)
    • The current politics of running IRC (specifically EF net, but any IRC network that grows to a certain size suffers this) make it impossible to improve the infrastructure.
    • IRCII's protocol makes you 'think' in a certain model. Nicknames. user@hosts. channels. Ops. This is an IRC mindset, not a communications mindset. FOlks comparing IRC to other systems need to remember that "/mode +o hax0rz" is not required in all systems, or there may be different approaches to things.

    Having said all that, I've been working a lot with Gale lately. It's encrypted end to end. It is NOT 'hard linked / single path' - in fact, the servers are loosely coupled. The concept of 'nicknames' doesn't exist. Everyone is a user@galeserverhost. The only way you can connect to a gale server is if the owner of that server signs your key, and the owner of that server has to have his server key signed by the Gale authority before they can connect to the rest of the network.

    The entire system has been running for a year or two now, and we're in the process of taking the next step in the protocol. There are several clients available, and the active community on the network is communicative, intelligent, and always contributing.

    Tired of IRC? Try gale. http://www.gale.org/

  • All valid points. But aren't 1 and 2 inherent problems with any public key system?

    3 is probably the best criticism, and it will be hard to address. What about this, for each person you want to talk to on the channel, you select their public key out of your trusted keyring, and anyone in the channel you don't trust, you can just not select their key. You won't have to do this for each message, you can select which keys to use for every message in each channel, kind of an add/remove type function. That way if someone walks in the channel, they won't happen to see anything but encrypted garbage, until you add their key to your ring, and select them in that channel. Even the admins couldn't see anything but encrypted garbage. This of course requires a lot of client modifications, but if we came up with something standard, I am sure Kahled would be a willing listener, one who doesn't have to follow stupid US encryption laws either.

    Problems with this idea include weakning the power of admins to be able to tell when abuses occur. They would be able to tell if someone is flooding the channel, and obvious things like that, but as far as harassment goes, it becomes hard to prove what text was actually sent. It already is kind of hard to prove, and there has to be a level of trust that the "victim" didn't modify log files.

    Let me know what you think about these ideas. My original message was more critical of the undirected negativity that I saw on here, I think its good to talk about the weaknesses of the system, in a constructive way.
    -
  • The Gale [gale.org] secure messaging service is in version 0.99a. FAQ [caltech.edu]. The name is a takeoff on MIT Zephyr [mit.edu]. Goals include scalability as well as security. The Gale documentation [gale.org] has a page comparing Other secure instant messaging systems [gale.org].
  • > wouldn't sending encrypted data be terribly inefficient for this kind of task?

    I don't think so. If you've got good compression the numbers comprising your compressed file is statistically random. If you've got good encryption, the same is true.

    QED?

  • Can you "pipe" its output to the E-Toilet [theonion.com]?

    dink!

  • You are real smart-like. Is that so you can IRC as root?
  • not necessarily,

    If you receive public keys from all users in a channel then its simply point to point encryption whenever you receive a message. Since the server probably will only forward instead of participate its not going to decrypt the info. I am thinking that keys are only exchanged between channel participants. In a busy channel that could be interesting as far as processor time on al the crypts is concerned.

    In such a situation only a human or bot participant could log the conversation.

  • You're such a fucking troll. Of course IRC is meant to share conversation. Of course encryption won't help you be anonymous. The whole point is that sometimes you want to have private conversations and people with packet sniffers on the servers can just listen in and eat their carrots. Dave
  • by Bostik ( 92589 ) on Saturday September 30, 2000 @01:49AM (#743320)

    It seems secure IRC-like systems are spranging up. Quite understandable. From the land of Linux comes one.

    SILC [silc.pspt.fi] takes a new approach. It's not about adding encryption via SSL to existing networks, but building secure network and clients from ground up.

    And no, it's not intended as a replacement for IRC. It's an alternative. - And if I understood C any better, I'd be developing this one as well.

  • C'mon people, we live in a graphical world -- kick those VT220's to the curb!

    Er, hello. GUI-based clients for IRC appeared about two milliseconds after the original version. The fact that text-based ones are still around just gives extra capability --- you can chat on IRC while on the move through your mobile, or when connected through a public access telnet. You'd have to forgo communication until you reached a fixed infrastructure if there wasn't a plain text interface to IRC.

    The rest of the world has moved on to ICQ, various instant messagers, Yahoo Chat, CheetaChat and other avatar chat programs. IRC is featureless and looks positively dowdy in comparison.

    And with all that prettiness, exactly how much communication gets done? Compared to IRC, very little. A picture is only worth a thousand words when the picture is specific to the message, not when it's a prepackaged icon or avatar, otherwise it's merely eye candy.

    A top-band communication system would give you text, a whiteboard, and voice. The examples you cite are merely examples of graphics misused.
  • by h1kari ( 238532 ) on Saturday September 30, 2000 @01:54AM (#743322) Homepage
    I am one of the suidnet admins and I'd just like to comment to some of the posts here to make things a little more clearer.

    Suidnet is a very new network, it has only been around for less than a week and we're still working on getting the kinks out, and we have never fully guaranteed security. All we do guarantee is that your link to the server and the links connecting the servers will be encrypted and that we are trying our best to ensure that all of the servers are secure. This is not fully implemented yet, but it will be within a week, so please do not exchange sensitive information until notified on the website.

    Currently the ircd source is experimental but will be publicly released when fully finished (it is based on hybrid6rc4). I can say that we use stunnel to ssl wrap all of the connections between the servers and for connected clients (useful for running one server for encrypting/decrypting and one for ircd). I can also say that we only made modifications to the ircd to obtain hostnames of users connected through stunnel and to append -insecure to unencrypted connections and that none of them are run in debug mode.

    The basic idea is that unencrypted users get -insecure appended to their hostname so if you are connected securely and want to run in secure mode, you can /ignore *!*@*-insecure, or if you want to run a secure channel you can /ban *!*@*-insecure, etc.

    Oh, and all of the swapping of MP3s and kid porn that is done over /dcc will not be encrypted unless both ends run irc clients that encrypt dcc. We can't even guarantee that dcc will work the same as with normal irc yet.

    Any/all comments are welcome as always, and I'm glad to see all of the discussion going on here on /.

    -Ttyl

  • Encrypted IRC is something I've been thinking about for a long time, and have been waiting for someone to do just such a thing.

    Now it's out, I hungrily go to their page, desperately seeking the sources, and find, lo and behold, them to be nonexistant.

    Unstable code or not, the power behind IRC is the fact that if you don't like the way the community is looking, you can always find make your own. I've seen proprietary IRC networks try to strive and fail miserably [another.net].

    Suidnet guys, I think this is a beautiful project, and I am completely interested in how it's progressing... but I'm a bit disappointed that it's not open.

    I congratulate your effort, as you've done something that has been desperately needed for years...

    But until anyone can set up their own encrypted IRC server, it's just another AnotherNet.

    Quarterdeck Chat? TalkCity? Those are other stories....

  • All we do guarantee is that your link to the server and the links connecting the servers will be encrypted and that we are trying our best to ensure that all of the servers are secure.

    Ok, but who guarantees me that the administrators of the IRC servers don't modify the ircd source so that they can listen on my conversations? After all, only the links are encrypted, but the ircd still gets to see all traffic in plaintext.

    It's good to see an IRC network with fully encrypted links, but I still wouldn't want to use it to "exchange sensitive information", because if I don't want to trust sniffers, I also don't want to trust IRC admins. For that, client-to-client encryption is needed.
  • you forgot local server channels ;) &(channel name)
  • Yeah, I never worry abou the "jumping through hoops" attacks. My approach to security is simple -- if its hard to do, its not worth doing. I assume everyone else uses the same approach. Oddly enough, the same philosophy works for backups, too.
  • I was looking at the FAQ for suidnet, and found this:

    Q: why does xchat not connect and/or give me cert errors?
    A: because xchat's ssl support is gay.

    This is an interesting concept. Can someone please tell me what I have to do to make my programs gay? I think the software world needs more diversity. Almost all the programs I have seen have actively denied being "gay" and I think we need more programs "out of the closet". Does anyone know how to program sexual orientation in C or C++? Do I have to use the select() function?

  • I get sick and tired of people constantly waving "kiddie porn" as a reason to give up all our rights. "You can't have privacy, you can't have P2P file sharing, you can't use the internet, and you can't access porn among consenting adults. Why? Becuase you might be a child pornographer!"

    (sarcasm)

    Hell, lets outlaw cars! They can be used to conduct bank robberies and kidnappings! Lets outlaw cameras! They can be used by to take pictures of naked children!".

    Lets outlaw freedom! It can be used to do al sorts of heinous acts!

    (/sarcasm)

  • by Anonymous Coward
    Gee, look, just like efnet.

    *** Looking up irc.suidnet.org
    *** Connecting to 199.245.246.35
    *** Connected to irc.suidnet.org
    [s] *** Looking up your hostname...
    [s] *** Found your hostname, cached
    [*] Disconnected from irc.suidnet.org:6667 [Closing Link: xxxxxxxxx.xxxx.uswest.net (No more connections allowed in your connection class)]
    *** Disconnected from irc.suidnet.org
  • >Ok, but who guarantees me that the administrators of the IRC servers don't modify the ircd source so that they can listen on my conversations? After all, only the links are encrypted, but the ircd still gets to see all traffic in plaintext. No shit genius. But are your conversations hidden from the ircd/admins on an unencrypted server ?! Your point affects all ircds, not just this one. Simply because this server doesn't answer one of the problems with irc, doesn't take anything from the validity of the OTHER problems that ARE answered by it. It's a step in the right direction.
  • Dumpster diving is already recognized as a cheap hack method, one of these days we'll have insurance companies intercepting our sewers to perform dietary and DNA analysis, we'll have the government checking for drugs and who knows what else.

    We'll need a properly implemented SJohn to keep our excretia from prying analysis!

  • Because IRC has encryption support does not mean that the network will be drawn to its knees. Fact of the matter, most people probably won't even use it. And thats ok. Many conversations don't need to be encrypted, but it would be nice to have the option available if I wanted it.

    Encrypted options will probably only be used by about 5% of the users, so there won't be any significant toll on the network.

    -Restil
  • What is the point of ignoring people who aren't "secure"?

    What if you don't wish to speak to people unless you know it's secure ? What's the point of having YOUR link to the server encrypted, if the guy you're talking to isn't encrypted ? The plaintext will flow to him and ruin the whole idea.
  • Now it's out, I hungrily go to their page, desperately seeking the sources, and find, lo and behold, them to be nonexistant.

    Unstable code or not, the power behind IRC is the fact that if you don't like the way the community is looking, you can always find make your own.

    I've spoken with Push, one of the admins, and he says the source isn't ready yet. Besides they've already explained what it is. Hybrid with stunnel and a slight mod for unencrypted connections. 99.99% of the source is known. Calm down and give em a little time before you berate them for not providing the source.
  • C is hetro.
    C++ is bi, but prefers butch women.
    PASCAL is a transvestite.
    FORTRAN doesn't have an active sex life anymore.
    Visual BASIC is gay, but pretends it isn't.
    Perl is very clearly, gay and proud.

    PLEASE MOD THAT UP. THAT'S TOTALLY FUNNY
  • Decentralized/peer to peer IRC ? Are you out of your mind ? Look at Gnutella.
  • I understand what your saying bro, but I have a slightly different take on this.

    The best way to deal with kiddie porn is with a good f_king deal of violence in my opinion

    Ok, now before you think I'm trolling here, let me explain my position. I've worked for years as a technician in the Australian District courts, and unfortunately we tend to get alot of Rock-spider pedophiles through here.

    Phuck free speech when it comes to abusing children. I've had to deal with far too many suicides and absolutely horror-trashed lives from evil pricks abusing children

    Fact A: When a rock-spider creates child-porn (Free speech?), he(or she) is quite likely screwing up that kid for life.

    Fact: Sexual abuse is a No#1 cause of suicide and major lifetime depression

    Ergo: Sexual abuse(free speech apparently) causes death.

    I'm not getting hysterical here. I've seen it directly too many times.

  • Oh.. While I'm at it.. I'm not arguing with most of your point. I agree freedom is a precious thing, and yes, I probably am being a little hysterical in my connection of free speech to child abuse.

    However, I tend to believe that freedoms beget responsobilities. And as Sartre might put it, freedoms are infact precursors to responsibility.

    To suggest that going after child-abusers abrogates free speech, ignores that the Child-pornographer has made an (authentic?) decision, within the context of free speech to abuse a child. To not put responsibility on the person who chose to use their freedom this way is in a sense bad faith(in the Sartre use of the term).

    It's perhaps that freedom-until-your-nose thing. It's alright to use your freedom to do what thou shalt, but it's certainly not alright to use that freedom to destroy a childs life

    And on that subject , in my IRC days, many moons ago, a favored past time was invading child-porn channels and nuking the crappers out of them.

    And that is a positive act of good-faith freedom.

  • What IRC really needs is not a new, secure, indipendant server; it needs its existing servers to crack down on "packet-junkies" and channel takeovers. I watched as a teen-ager on his daddy's computer take over a channel that I was in with ease because of EFnet's lack of security. EFnet, Undernet, and the like need to really crack down on stupid 14 year old kids with a cable modem that decide to use their fathers large amount of bandwith to ride a netsplit down the throat of a channel. (Not to mention they should really do something about netsplits. there just damned annoying.)
  • by pb ( 1020 ) on Friday September 29, 2000 @11:59PM (#743340)
    Can we make it completely anonymous, too?

    That way, no one else has to know who you are, or what you're saying... wait, if I wanted that, I could just lock myself in the closet...
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
  • While security is always great to have, wouldn't sending encrypted data be terribly inefficient for this kind of task? Encrypted communications usually uses up more bandwidth per sentence than unencrypted communications, and given the decentralized nature of IRC, it seems like you'd have a lot of extra text shooting back and forth from computer to comptuer. This could really slow a lot of networks down -- believe me, I've seen plenty of channels where the text flies fast and furiously.

    It's impossible to ever obtain absolute security, and the more security we have, the less convenient and powerful our programs are -- remember, the scripting in Outlook may be a security hole, but it's also a honestly useful feature for a lot of dumb secretarys. IRC doesn't seem like a medium where a lot of security is really necessary; I don't see any reason to sacrifice speed to keep A/S/L checks and MP3 begging encrypted.

  • by StandardDeviant ( 122674 ) on Saturday September 30, 2000 @12:08AM (#743342) Homepage Journal

    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, yeah, if you want to chat at work without "the man" hearing everything, this is a pretty important development. :^)


    --

  • Wow if that part alone gets pulled off, maybe I will start using "public" IRC servers again. The flood of kiddies and such on almost all channels, even moderated finally drove me to abandon IRC as a real com tool, although I do use it on private IRC servers to keep open conversations with select people.
  • This system will only work if you can be assured the ircd and the system on which it runs is secure. It is all very well knowing no one between the server can read your messages(but even that isn't assured) but there is a good chance that the ircd or the machine on which it runs can be breached, and then all the security is no use whatsoever.
    The system also is at risk from "man in the middle" attacks, where an adversary substitutes the server's public key when it is sent out for their own key public key, and decrypts the messages, reads and/or modifies them, then encrypts them with the server key and sends them on.
  • Do what I do - ssh to your ISP's server and IRC from there ;)

  • Why must encryption take up significantly more bandwidth ? (Maybe I've missed something there...) I believe the aim is to try and get rid of some of the things you point out as being worthless for encryption: MP3 begging, etc... IRC was long,long ago a useful tool for real-time communications. Unfortunately it has since devolved into a mess. Although the SUIDNET alone may not fix any of that, if, combined with good client IRC software, it manages to automatically filter out alot of the noise, or better yet keep defined channels clearer of the uninvited chatter, it would make IRC OP's life easier and users lives much better. I used to have IRC open and logged in all the time, now I very rarely ever se it (on public servers that is, I still use it all the time on private servers.)
  • From knowing people who've passed this knowledge down, either efnet/DALnet/ircnet server administrators or operators... IRC servers as much as anything else is huge on resources and bandwidth. It pretty common for an ircd to eat up more than 40MB of RAM in no time flat, not counting resources covering for buffered streams of data. Why do you think a lot of the major networks have tweaked their I:lines out so that clients can hardly even do so much as a /list so as to keep the server load down?

    There's little hope of this ever being implemented as a patch on any of the large existing networks if it's anywhere near as processor intensive as I'd guess this would be. Benchmarks, anyone?

    Perhaps for small corporate networks, but forget mainstream. And isn't that where we need it?
  • by Anonymous Coward
    I.R. Sea?

    Is that some sick programmer's parody of "I.R. Baboon"?

    Well, it won't work, because...

    I.M. Weasel!
  • It's a matter of trust. Who's to say that non-encrypted ircd's haven't be hacked to log every convo? It's generally a safe bet that most ircd opers are on the up and up, but there could always be someone with less scruples to do such.

  • A while back some guys in the Netherlands came up with the same idea and this is exactly what I told them. Their project is called Paranet and basically wants to do the same thing. Another problem is if the physical box is approached (any judgement department with the proper papers can order access to the machine) because then you can access all the data after it's unencrypted, perhaps even read stuff from memory in cleartext as well, etc. Like you said, there's more to security then encrypting connections :) Menso
  • by isaac ( 2852 ) on Saturday September 30, 2000 @09:56AM (#743351)
    We ditch the IRC model, which is fundamentally insecure inasmuch as it requires an extra layer of trust (the server op), who's in a prime position to be leaned-on by [insert powerful party].

    Something I haven't seen brought up in these discussions is traffic analysis. Foiling TA is the key to truly secure communications. This is tougher than it sounds, as there are many ways to glean info from an encrypted channel.

    The "Buddy List" (or, if you prefer, list of users on a channel) is the most useful piece of intelligence for any security force. Start with an individual under suspicion, watch who that individual communicates with, when, and how frequently, and you know who to investigate next. Encrypted message traffic doesn't affect this channel of info.

    Consider encrypted ICQ - messages may be encrypted, and broadcast point-to-point, every user's "buddy list" lives on AOL's servers. Every sign-on or -off is recorded. At this point, say you've got a "buddy" in your list who's sharing MP3s or hosting DeCSS. RIAA/MPAA subpoenas user's buddy list from AOL (whoops, since it's AOL/TW, a court order probably isn't necessary!). Now you are brought under suspicion or targeted for harassment, or otherwise dragged into a case you may have known nothing about.

    Now, this has me thinking, what would it take to defeat TA in an instant-messenger type product. I'm not a coder by any means, but I have a few ideas:

    • No centralized servers, of course. "Buddy lists" stored at each client, exclusively

    • Clients continuously send/recieve encrypted traffic to neighboring hosts. Within fixed-sized encrypted blocks there might be user messages (w/ routing information encrypted in an "onion skin" fashion, so that a routing host doesn't know the final destination of the message, nor its true origin), client messages (newly connected client advertising its presence on the network, etc), or padding, if necessary to fill space. Continuously sending and recieving fixed-size chunks means others can't trace messages by monitoring traffic volume over time.

    • The network should only support messaging. The latency and scalability limits to this system should be tolerable for text messages, but would be shot to hell by file transfer.

    Any thoughts on this? Anyone working on such a system already?

    -Isaac

  • ...forget the MPAA, one need only consider the tactics being brought to bear on anti-globalization protestors, including military assistance to police, police disruption of organization efforts ala COINTELPRO, etc. to understand why secure communication is critical to functional democracy (and why a police monopoly on secure communications is a cornerstone of authoritarian regimes).

    -Isaac
  • Getting WAY offtopic, but...

    PS- If you really want help your kiddie porn crusade, I suggest you contribute to developments in AI. If you accept the idea that people will eventually create a self-aware computer program, you can accept the idea that it will probably be used to monitor internet traffic.

    Thats the scary part about singularity that most of us don't want to see. Infinite power as such an AI could wield, should not be wielded for "social causes," or we are all in BIG BIG trouble. Think the ultimate Big Brother. We can only hope to not pass on our social goals into any seed AI that we write, if it would even be possible. (A lot of our society doesn't make logical sense from an external point of view. The AI may be too smart to fall victim to our socialization.)
    -

  • My god... I can't believe you people sometimes. You think carnivore is bad, and you pontificate about encryption being the only way to secure your email from the Government's prying eyes. Then this story comes out, and of the comments so far, no one has anything good to say about it.
    Encryption is a double-edged sword - It protects you against evesdropping when working correctly, but unfortunately it also makes you *feel* secure. The immediate question then has to be - if you feel secure, and start divulging secrets you wouldn't trust to an insecure channel, then under what circumstances could someone else gain access to that information? when will your trust in the security of the channel let you down? As I see it, there are several points of attack:
    1. Tunnel insecurity or MitM attacks
      Someone could compromise the security of the channel between you and the server, either by getting the server's key, getting you to switch to an insecure channel, or intercepting the initial communications so as to set up TWO encrypted channels, one from you to him, and one from him to the server.
    2. client insecurity
      Someone could hack, exploit loopholes in or plain replace your client with one that lets him spy. This also effects any logfiles you keep - you may think of them as historic data, but they are really a realtime window into what you can see, on a second-by-second basis
    3. Server insecurity
      This is a biggie, and needs dividing up
      1. Abuse of priviledge
        Server admins could (for example) activate logging on a channel to see what was said there - or create an invisible client for themselves so they are "on" the channel without being seen
      2. Exploits against the server
        A blackhat attacker could exploit weaknesses in the server software to gain admin priviledges, then abuse them as above
    These are just the first few points that spring to mind, and yes, the #suid people have done well (and more importantly, have gotten off their backsides and written this stuff rather than just sitting around saying how good it would be if someone did) but security, like fire safety, is something that needs a good hard look and frequent inspection.
    --
  • *** Connecting to suidnet.org (6667)
    -suidnet.org- *** Looking up your hostname...
    -suidnet.org- *** Found your hostname
    Welcome to the Internet Relay Network Jesse


    --

  • "Insecure" should be added at the beginning of the hostname, or used as the ident (since they're not using identd). Adding it to the end of the hostname makes it hard to set up good domain bans.

    --

  • CTCP is not an option if you need to communicate with more than one person and this is what irc channels for are.

    Second. I did not read specs. But I immagine that one could create a secure system where:

    1. encryption/decryption is made [almost] only on client computers;
    2. clients could complain to server that something is wrong with particular nick;
    3. server then could check next few messages from that suspectable nick and apply penalties either to one who supplied badly encrypted/forged data or who blamed on innocent

    As for increase in network traffic. 16 extra bytes per message for authentication is not a big deal when just tcp/ip header is 40 bytes long. And you could save more by changing full name of server to just id.

    For those who speak about central authority. If I have some friends who I communicate a lot I will have stored their id files (also I don't know if this is in this implementation) and my client could warn me if somebody other pretending to be friend of mine.

    All in all - I suppose this is good idea. The only problem - I could not find source for their server.

  • What is the point of ignoring people who aren't "secure"?
  • http://achurch.dragonfire.net/irc3/ [dragonfire.net] is a proposal called IRC3 that at least includes support for redundant links, by Andy Church (who originally wrote the most widely-used implementation of IRC Services currently available).
    I read through it a while ago, didn't see anything obviously wrong with it - although at that point there were still a few loose ends pointed out in the text. Problems with retaining sync across a redundant-link network, in particular (this is why IRC-II, the current protocol, specified non-redundant links).
    Other enhancements in IRC3 include better international support and features which should encourage better-designed IRC clients.
  • If you're up against opponents powerful enough that the encryption available in your IRC client or script isn't good enough, maybe you should be using PGP and email instead.

    ]$`};L(;/proc);[I(;];<C{;};1S[;`\/while=1E1L[`\p roc{>=

  • Having not visited ircnet recently, would I be correct in saying that +a moded channels are incapable of having it's inhabitants sending or receiving /msgs? Something doesn't seem quite right there with the aliasing, but can't put my finger on it...

    .siglost
  • The reason kiddie porn is almost universally outlawed is not because it is disgusting but because in order to create it you must sexually exploit a child.

    Yes, there is such a thing as a sexually precocious child, and a couple of recent studies have found (to great outcry) that there is indeed a matter of degree when it comes to traumatization, but there are enough ten year old Cambodian girls being conscripted into what amount to rape camps so that kiddie porn and child prostitution can happen that I can see the merits of disrupting the revenue flow at every level. It is not the content itself that is condemned, but the fact that a crime must be committed in order to produce the content. Therefore governments feel justified in supressing this material, because making kpr0nz unpossessible makes it unbuyable makes it unsellable makes it unprofitable makes it stop being an industry.

    The problem arises, though, that this model no longer applies. A digital camera and a modem can make anyone a pornographer. Plenty of Internet porn of the consenting adult variety is created without profit as a motivator. Kpr0nz are just as easy to produce. So now we face the dilemma that there is no revenue stream to disrupt: you aren't necessarily trying to destroy a commercial enterprise. The payment isn't money, but pride; sort of the Open Source philosophy as applied to naked people. But can even if certain transactions can be outlawed, can approval be outlawed as well? If it's illegal to sell it, is it illegal to give it away?

    So what can be done about people who sexually exploit children just for the hell of it? I am inclined to say that without a revenue model, the current kpr0nz laws make less sense. Nevertheless, the producers thereof are severe assholes for doing what they are doing, money or no money. I will cheerfully endorse their prosecution, not because of what they are making, but because of what they are doing.

    If we are back to a pure-speech issue about the material itself, whether to outlaw it becomes a somewhat more difficult question.

    One last question, just to thicken the stew: What about material in which no sexual exploitation happened? For example: if you have ever seen a picture of a supermodel doctored up so that it looks like somebody just ejaculated on her face, would a picture of Jean Benet Ramsey doctored up the same way constitute child pornography? Where was the sexual exploitation?

    --

  • Yes, Child Pornography is bad, very bad, but this should not be a reason to condemn technologies that may or may not be used to facilitate it. That is the crux of my argument, and why I get so tired of hearing about increasingly draconian laws and surviellance and big brother to stop so called pedophiles and terrorists.

    "Innocent until proven guilty."

    At least thats how it was supposed to work.

  • I tried Gale about 4-5 months ago. gale is strange. gale is basically encrypted zephyr without kerberos authentication. There are some nice things about gale, but it just didn't do what I wanted the way I wanted. YMMV.

    after trying Gale, I tried Jabber [jabber.org]. I think jabber is much closer to the answer I was looking for. I just wish it was closer to done than it is...and I REALLY wish there was a clearer map of all the jabber-related projects.

    All I wanted was an easy to set up and easy to use chat/messaging server with encrypted communication and strong authentication.

    IMHO,
    Michael
  • You have that backwards. When you ignore someone, you can't hear them- they can still hear you.

    Your words will be just as secure.

  • All valid points. But aren't 1 and 2 inherent problems with any public key system?
    Well, (1) is inherent in single-ended PK systems - If you used (for example) PGP keys in the mix, then you would have to compromise all the PGP keyservers; single-endedness is one of the known weaknesses of SSL.
    (2) is a specific weakness in IRC packages - I am not saying that the software you choose does have that weakness, just that many security loopholes have been found so far, and more will be in the future. IRC software is often not secured against such attacks, as it isn't normally security-critical.

    3 is probably the best criticism, and it will be hard to address. What about this, for each person you want to talk to on the channel, you select their public key out of your trusted keyring, and anyone in the channel you don't trust, you can just not select their key.
    Yep, that was (roughly) the approach that occurred to me too. However, I was thinking in terms of Session Keys for a channel - so (assuming a PGP overlay) the first person on channel generates a session key; The second person online must request the key from the channel founder, via a PK encrypted request and reply (keys from the public servers, not implicit of trust). If the two have an existing relationship, the channel is marked trusted; if the two don't have an existing trust relationship, but the channel founder hands over the key, then the channel is marked secure-but-distrusted; if the channel founder refuses the key request, the channel remains dormant, but the new user remains on the external waiting-for-admittance list (structurally, this will look like a join-refused to any external IRC package; some new commands would need to be added between the IRC package and the interface module handling the encryption so the user could check his waiting status)
    Ok, now a third party joins; if he is trusted, then he gets the session key and the channel owner sends to him the current waiting list; anyone on that list HE trusts he then contacts and invites to the channel, thus maintaining the trusted status; there is some additional stuff I have mapped out about doing a trust-check to upgrade secure-but-distrusted to trusted; basically, there is a rekey event, and it is handed to all the trusted users via the "hard" trust relationships; if any untrusted users remain, they either receive the key via the old session key (a soft upgrade attempt) or are excluded from the channel (a hard upgrade)

    This of course requires a lot of client modifications, but if we came up with something standard, I am sure Kahled would be a willing listener, one who doesn't have to follow stupid US encryption laws either.
    One of the advantages of the scheme I came up with was it could be done entirely from a "gateway" app, similar to the one used to provide SSH functionality to apps that don't support SSH. As it would inherently understand IRC, it could handle ping/pong events, the encryption/keying and rekeying itself, and support "additional" commands that trigger events (similar to bot ! commands, but not displayed on the channel)

    --

  • Absolutely not. The key is in your excellent choice of the word "misapplication." If I use a car to mow down a pedestrian instead of to convey me from one location to another, it's still my fault that the pedestrian was injured/killed, not the car's. If I use a steak knife to stab someone, does that mean everyone has to stop eating meat because they will not be allowed to have utensils with which to cut it?

    My stance on gun control is the same as it is on vehicle control, steak knife control, and technology control: fix the societal ills that produce people willing to commit heinous crimes, and there will be no need to control the tools and implements with which the crimes are committed (and which have perfectly legitimate and society-benefitting uses). And if you (generally and collectively) are not willing to fix those ills, then you must tolerate the crimes. What it mostly boils down to in my mind is the lack of proper parenting in the current and immediately previous generations. If we as a society raise good parents, then within two generations most of our violent crime, drug use, child abuse, etc. will be gone. It may sound Utopian, but if you think about it you might start to agree with me.

    </rant>

  • Real security doesn't just come from encryption. Enscryption will protect you from some guy with a sniffer casually dropping in and listening in on you. That significantly raises the bar.

    The next question you have to ask is if you trust the operators of your network. Did they (intentionally) hack the ircd to give them a copy of all traffic? Did they (unintentionally) leave some security hole open on one of their servers?

    This is a big step forward, but don't think that this protects you from everything.

    --Kai
    --slashsuckATvegaDOTfurDOTcom

  • by GigsVT ( 208848 ) on Saturday September 30, 2000 @12:27AM (#743369) Journal
    My god... I can't believe you people sometimes. You think carnivore is bad, and you pontificate about encryption being the only way to secure your email from the Government's prying eyes. Then this story comes out, and of the comments so far, no one has anything good to say about it.

    Don't you think the Government already has some sort of monitoring system for IRC? Don't you think that this would at least provide some higher level of security than none at all? Sure, none of you all will admit to using IRC, but that doesn't matter, because hundreds of thousands of other people do use IRC, and in the end, we are the ones that know how to protect ourselves, they are the ones that don't.

    I think this system is a good idea, and while some of you have valid points, there are limits to the security of a public messaging system. After all, all security eventually boils down to trusted authority regarding identity, which is something IRC may never have.
    -
  • Well, having a more secure irc can't be bad. currently many corporations
    block irc traffic with security as an excuse, with the real reason ofcourse
    that users should not be wasting time on irc anyway.

    But currently irc is a security threat, as the favourite hobby of
    script kiddies is invading channels on irc. However, I don't see how ssl
    connections to IRC will make it any more secure. Ofcourse, you can't
    be sniffed, but channel/nick invasions remain.

    personally, I have better expectations for silc [silc.pspt.fi],
    which seems to be IRC Done right.
  • Privacy is a good thing... but what about those trading kiddie porn via IRC? Will they be more able to "slip through the cracks" with a system like this in place?
  • by Isomer ( 48061 ) on Saturday September 30, 2000 @12:35AM (#743372) Homepage
    All IRC is, is a glorified multiplexor on steriods
    with delusions of grandeiur. If all the links are
    encrypted from clientsservers then how much security have you really gained? Noone can sniff your network, but do you trust the admin's of the servers not to patch the daemon and sniff your traffic? What about the local SS coming and forcing you to install those patches? You'd be far better to extend the CTCP (Client To Client Protocol) that runs over the top of irc to support encryption. IRC already has this in the 'SED' CTCP, which unfortunately isn't too secure. Someone with some spare time could easily hack this up.

    The next point is how much cpu do you have? Encryption is
    all very fine, but having the servers do all the work causes all sorts of problems, when you hit 10k clients per server as some networks have done how much cpu are you going to need to use then?
  • Is life so dear or peace so sweet to be purchased at the price of chains and slavery? Forbid it, almighty God. I know not what course others may take, but as for me, give me Liberty, or give me Death.
    -
  • >Supper secret IRC command that will let you do this.... /join #(channel name)
    Ever heard of "invite only"? This would also let the people on the channel see that you're there.
    >IRC is more like a club.. Everything is public and quite a few people are jerks.
    This doesn't mean that I shoul accept that any jerk treats me like shit(or listen's to private conversation, or whatever)
    Just because it traditionally IRC have been easy to spy on IRC users doesn't mean that it should be.

    --
  • Or another one(these people have a server up and running) Read more here [www.sirc.hu]..
    If you don't speak hungarian you can always try it by
    1)Install stunnel<PLUG>(apt-get install stunnel)</PLUG>
    2)run "stunnel -c -d localhost:6667 -r segfault.sirc.hu:6657" as root(I don't know if it's the same syntax for MS windows).
    3)connect to localhost:6667 with your favorite IRC-client.

    --
  • Even though there seems to be nothing on the SourceForge site, I'm still much more interested in the redundant-link IRCD than the encryption.

    I don't need encryption on IRC. I'm not a tinfoil-hat-wearing psycho, afraid that THE MAN is going to snoop on my takeovers and age/sex checks. However, I'm a big-time EFnet user, and one sure way to stop the recent EFnet problems - huge splits - is with redundant links.

    The current network is laid out with hub servers and leaf servers. The IRC protocol forbids any link that would provide more than one path for a message between two given servers (a redundant link). That means that if big hub irc.exodus.net loses its connection to big hub irc.best.net, the network is split into two sub-networks of roughly equal size.. the worst kind of split.

    If redundant links were allowed, each big hub could link to every other big hub, and smaller hubs could link to more than one big hub. When a hub connection dies, there's already another connection in place. The result? No split.

    ]$`};L(;/proc);[I(;];<C{;};1S[;`\/while=1E1L[`\p roc{>=

  • by Bake ( 2609 )
    well, there is (on ircnet at least) a channel mode that sets it anonymous, so you won't see
    "nick!user@host joins #whatever", you'll see
    "anonymous!anonymous@anonymous joins &whatever"

    The trick iirc is that you have to join &channelname (ampersand instead of hash) and set the +a channel mode on.

    /mode &whatever +a

    This is however not 100% securely enforced, but along with secure-irc it would be close enough :)
  • Why not use something like IPsec for this? it encrypts
    the network traffic and requires no changes to the server,
    and gives you the same amount of protection.

    The redundant links idea has been thrown around irc for years,
    and runs into some serious problems, for starters irc is very prone to 'desyncs', and
    many of the serverserver protocols aren't atomic with respect to a command, causing more
    desyncs. It basically ends up with you sending all the data multiple times which isn't really practical. And even if you could, if a servers unreachable, it's unreachable, no number of TCP connections will stop it from splitting.
    A lot of the splits on the major networks today are due to DDoS attacks against ISPs and/or the servers.
  • by soulsteal ( 104635 ) <soulsteal@@@3l337...org> on Saturday September 30, 2000 @12:54AM (#743379) Homepage

    Today was the announcement of the encryption toilet, SecureJohn (SJohn). When flushed, it scrambled it's contents as to render them useless to prying eyes. Microsoft has chosen to implement it's own version in it's latest OS with stand alone versions available for purchase. While MS John will not be full compatible with SJohn, open source proponents are rumored to be working on OpenJohn for the various flavours of Unix.
    Back to you CmdrTaco.

  • Telnet is me using my computer.. I should protect that connection with encryption (Not against the government but against script kiddys)

    E-mail is a personal message from me to someone else.. this privacy should not be invaded.

    IRC is a public chat.. You allready have no privacy on IRC.. Want to see whats being said on a given channel? Supper secret IRC command that will let you do this.... /join #(channel name)

    Packet sniffing will let you observe chats on channels you were banned from.. big deal... It's not private... The most you can do is secure a channel from some jerk flooding the channel with "I am the lizard king" or "Hay babe want hot sex?"

    E-mail is well mail.. how would you feel if someone openned your personal mail?
    IRC is more like a club.. Everything is public and quite a few people are jerks.
    When when you kick the out they can still look in the Windows.

    I'd be annoyed if someone was reading my e-mail to my GF but spying in on a chat with friends on IRC is pritty much fair game... big deal
  • Why not use public key encryption with irc? Ie, each users client creates a private/public key when connecting to the server, and gives the server the public key. Everytime you join a channel, every user in that channel downloads your public key, every message they type gets encrypted with every public key (I believe this can be done so that if you encrypt by password a, b, and c, either a, b, or c can decrypt, alone) and distributed to every person in the channel. Your client decrypts with your private key. Same for private message, and then you don't have to worry about the admin sniffing because he can't. Sound workable? It would be more processor intensive, but at those transmission speeds (as fast as a human can type) that really isn't an issue even for a 386.
  • http://www.flat222.org/Paranoia

    will perform similar functionality (and other stuff), and also be more secure ;)

    NOTE: It's very much "in development" at the moment...

    best wishes,
    Mike.

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Working...