Slashdot Mirror
IRC Improvements
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.
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.
to accept the praise of personal wisdom is an affront to the very ideal i hold dear.
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/
Event Management Solutions : http://www.stonekeep.com/
The Gale secure messaging service is in version 0.99a. FAQ. The name is a takeoff on MIT Zephyr. Goals include scalability as well as security. The Gale documentation has a page comparing Other secure instant messaging systems.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It seems secure IRC-like systems are spranging up. Quite understandable. From the land of Linux comes one.
SILC 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.
There is no such thing as good luck. There is only misfortune and its occasional absence.
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.
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....
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)
www.enthea.org
We'll need a properly implemented SJohn to keep our excretia from prying analysis!
Bleh!
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
Play with my webcams and lights here
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.
pb Reply or e-mail; don't vaguely moderate.
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.
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. :^)
--
News for Geeks in Austin, TX
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.
X-Has-Sig: yes
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?
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:
Any thoughts on this? Anyone working on such a system already?
-Isaac
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
...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
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
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:
- Tunnel insecurity or MitM attacks
- client insecurity
- Server insecurity
- Abuse of priviledge
- Exploits against the server
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.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.
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
This is a biggie, and needs dividing up
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
A blackhat attacker could exploit weaknesses in the server software to gain admin priviledges, then abuse them as above
--
-=DaveHowe=-
-suidnet.org- *** Looking up your hostname...
-suidnet.org- *** Found your hostname
Welcome to the Internet Relay Network Jesse
--
The shareholder is always right.
--
The shareholder is always right.
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?
--
This is not my sandwich.
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)
--
-=DaveHowe=-
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
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.
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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?
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.
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.
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.
Tales from behind the Lagom Curtain