Slashdot Mirror
Linux Crypto Packages Demolished
SiliconEntity writes "Cryptographer and security expert Peter Gutmann has demolished several Linux security software packages in a recent posting to the cryptography mailing list. He says, 'It's possible to create insecure 'security' products just as readily with open-source as with closed-source software. CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed.'"
I wish I could make this my signature (damn 120 char limit):
"Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment."
--Peter Gutmann
I only use the Cyrillic Projector code. No one ever will crack that.
This is open source, figure out where to submit your patches or else you are nothing but an arm chair security expert.
Demolished? Where am I now gonna get my SSH and GPG from? :-(
Use ISO 8601 dates [YYYY-MM-DD]
What about the poptop project at http://www.poptop.org/. There is also a really good client package at for pptp servers at http://pptpclient.sourceforge.net/ I use both and they seem to be much better then vtun and cipe.
When I investigated CIPE for the first time two days ago, I read somewhere on the site that it didn't work yet, or that it provided no security. How can you critize a package for being insecure when they tell you it is?
Did I miss something?
he points to CIPE, a tool which hasent been updated since jun 02 and Vtun since aug. 2001. he says TINC was just as bad but was fixed when users complained. I think the obvious conclusion is that if people use the software and email the person who maintains it, it will get fixed. if the project goes stagnent because the author doesnt maintain it or people dont use it then of corse it will be vunerable after time as more flaws are discovered and not patched.
It's possible to create insecure 'security' products just as readily with open-source as with closed-source software.
This sentence can be reduced to "It's possible to create insecure security products" without losing any important content.
The question should be, is it possible to create a truly secure product when there's no opportunity for public code review? My answer would be "no". I shudder to think of how many critical holes would be found in most popular closed source network products if people like Michal Zalewski were allowed to review the source code.
All these years after Phil Zimmerman released the original PGP code, we STILL don't have anything which satisfies the need for a securing email. It would have these properties:
1. Be under a BSD-ish license, so it could be linked in to commercial and non-commercial products.
2. Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
Let's see, the Xiph people want their protocols to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmmm, seems to be working. The PNG backers want their format to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmm, seems to be working. The PGP/GPG people want their stuff to be used by people to send mail everywhere, so they make it either a non-Open Source license (PGP) or a GPL license (GPG) and also never ever make it a library for non-existant "security" reasons. Guess what! No one uses it!
Oh, and while I'm ranting about the horribleness of Open Source security stuff, why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.
He's talking about CIPE and pals...
.. I found CIPE thinking it was an IPsec implementation.. a quick perusal through the source code and docs made it appear to me that it was basically somebody's homebrew project designed with little regard for security. IPsec has its problems, depending how you set it up, but this was worst.
I remember when I installed Red Hat I went looking for IPsec
The 32-bit CRC thing caught my eye as well. I'm no crypto export but I know enough about it to remember how CRC-32 is a weakness of the SSH 1 protocol.
I have since set up freeswan and am happy with it even though I really don't understand IPsec that well I think it has been more closely scrutinized.
So yeah, the author is probably right when he calls it the open-source PPTP... I don't see what it has to do with open-source or closed-source, although with open source it was easy for me (and the author) to gauge the quality of the code and avoid it.
One can browse a manual on the topic and write an implementation that technically works (when paired with a similarly shoddily-designed decoder), but be fully unaware that the pseudorandom generator is just that. Or that the ones-complement portion of the crypto engine fails when X=0, weakening the whole thing by sixteen bits while not producing garbage.
Unlike a crappily-designed game, it's a lot harder to spot when crypto goes wrong. And most of those thousands of eyes supposedly peering over the code aren't looking that hard.
I'd still contend that commercial crypto has had more and bigger flaws overall, but he's right that the open source process alone isn't going to give you good crypto.
Nice posting a denied link.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
I checked the wrong damn box.
I hate Mondays.
Instead of making yourself look so great by "demolishing the security," why not offer the fixes? Yes, open source can be insecure, but at least it will be public knowledge what those insecurities are, and concerned individuals can make the mods themselves.
#1 Links to URLs not on standard ports stink. I'm stuck behind a very strict http proxy.
#2 Links to message lists stink to. The location of the content is not obvious. Maybe the offport link contains some valuable information.
#3 I did find the message that is the topic of this post. The material in the message seem very "dated".
No more Micro$oft bashing from me. Its like bashing at the special olympics.
Humans created computers.
.5 cents :)
Humans are inherently flawed.
Humans created the software
Then it makes sense that software would be herently flawed.
My
The time it takes to fix software is inversely proportional to the popularity of that software. I know 0 people that use CIPE and vtun.
Back in the day, whenever I'd bitch about how window managers lacked basic functionality, how the default IP tools didn't do multiple hot-switchable configurations, about the lack of decent documentation in the distro, about some aspect of the application that didn't work, shouldn't work that way, or had TOO MANY OPTIONS.... the response was ALWAYS "dude. The source is THERE. FIX IT YOUR OWN DAMNED SELF." With "That's a FEATURE, not a BUG." being a close second. To which I'd usually reply "I'm an ARTIST, not a CODER," resulting in a flamewar about the quality of the Gimp, but that's a different story.
:D
Things like this will get fixed when the people maintaining the packages start doing the gruntwork that gets those little bits enterprise grade- in other words, doing the hard, annoying, pain in the ass shit that you pretty much have to get paid to do, because nobody wants to do it in their free time. Big bonus points to open source software companies for making a BIG effort to do exactly that.
Unmaintained software........unmaintained.
In other news, Bear shits in woods.
The key to secuity is G(3X/J^G)
Where G is the speed of the computer, X is the length of the key and J is the time it takes to encrypt it.
For maximum security at low cost
G = 10 Gigaflops
X = 25 bits
J = 10 minutes.
Erm, no. Linux is considered more secure than Windows because it DOESN'T LEAVE THE RPC PORT OPEN BY DEFAULT, and a billion other things.
Look, we're not talking about Syllable or OpenBeOS or something here. Linux has 20 to 30 million users worldwide, and yet it never has anything like the massive problems Blaster and SoBig etc.
Do you read Slashdot!?! Since when are we anti-monopoly or anti-Microsoft for that matter? Troll.
*giggle*
Maybe not the bugs that are found, but I think all code on average starts out with pretty much the same amount of bugs, quite simply because programmers aren't perfect. In time, they iron out the bugs and it gets better.
That's why I hate it every time there's an exploit in a major package and some people go "Switch to our pre-alpha sourceforge package that's *so* much better and safer". Maybe because a bunch of crackers/hackers/developers (usually in that order) haven't looked it over and found the subtle exploits yet?
Kjella
Live today, because you never know what tomorrow brings
Thats true but it does not matter.
The quality of open source software is directly related to its desirability / popularity, in general.
things like ssh, pgp, and mozilla are pretty high quality, and have fast turn arounds on bugs. Not perfection, but quite efficient.
I'm pretty sure there are some pretty pathetic, sad window managers out there too. Some of the text editors are rather less than impressive as well. There are all manner of dodgy MP3 managements systems. OSS creates all manner of bad software because ANYONE can code something up and release it.
The security and cryptography field just highlights the problem because there are so many opportunities to do something particularly stupid in those fields. Anyone can write a cryptosystem that they can't break themselves. Unfortunately a lot of people figure if they can't break it, then neither can anyone else...
Jedidiah
Craft Beer Programming T-shirts
Linux in general is more popular than this project. That popularity gives it more eyes to keep watch on it, and shorter turnarounds when problems are found.
As for this project (CIPE), I personally have never heard of it. Indeed, neither has the poster from that mailing list: A friend of mine recently pointed me at CIPE, a Linux VPN tool that he claimed was widely used but that no-one else I know seems to have heard of.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
"Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment."
Don't hold back, Peter. Tell us what you really think!
20 - 30 million users? Thats all?
Windows has about 20 - 30 BILLION users and about 20 - 30 million PIRATED USERS....
Let me know when Linux starts to add about 3 more zeros onto their numbers.
Thanks.
What's even worse is that some of the flaws were pointed out nearly two years ago, but... some of the protocols still haven't been fixed.
Unacceptable.
There's no other way of putting it.
This crap got modded up??? I felt sure when I first saw the comment that it would it -1 at mach 3. Especially in light of articles like this one.
Not only that, but if you think about it, blaster and slammer and all those thing... They were only single "attacks", writen presumably by one single person. The nature of the insecurities is what allowed these worms to be as disruptive as they were. You imply with your post that the security of a system is inversely proportional to the scale of the deployment of that system. I'd love to see some evidence of that.
noah
Vtun is still far from being useless.
Just turn off vtun encryption and use it via a ssh tunnel. That works very well (i use it for securing wifi) and uses a proven protocol.
I also believe this is good practice and should be a widely accepted policy - re-use of good and proven software is not lame - it is crucial for easy, fun and secure software development. There really is no need for re-inventing the wheel.
Now if only ssl were so integrated into the operating system that i could use select() on a ssl-socket created with socket(), and thus making writing of ssl-enabled apps as easy as non-ssl-enabled ones, that would be great!
-- Having problems sending big files over the net? Try out Efisto (http://efisto.org)
FreeS/WAN
The real "Libtards" are the Libertarians!
You guys keep on bringing up the same point, though I don't think you know what you're saying. If you aren't trolling, please provide light and further understanding instead of what seems to be an unfounded assertion.
If you are looking for a good vpn package for linux, try openvpn:
openvpn
It was created a while back when all the other linux vpn products were not that great, and it seems like thats still the case.
Of course it'll have a similar number of holes. After all, there's nothing about OSS that makes the software fundamentally more secure. BUT:
1) These holes are far less likely to be in the base operating system implementation, as the OSS mantra is generally to put as much logic in user-space as possible.
2) These holes won't be covered up and released only after the vendor has decided to let us know about them.
3) These holes will be fixed up very quickly (in general, anyway), in individual patches or point releases, without onerous licenses attached to them, and without fear that the release might break the rest of my operating system.
4) Because OSS products use open standards, if one particular package is simply too insecure, at least I can change to another product and have things interoperate (eg, switching from Sendmail to Qmail/Postfix/MTA-de-jour).
This is one of the biggest flaws in the OSS mentality, this "shut the hell up and fix it yourself" nonsense. I've seen it countless times, as I'm sure almost everyone reading /. has, and it's one of the reasons why mainstreamers don't like Linuxites. It's also one of those things people here do that makes Bill Gates grin like the star quarterback getting a hummer from two cheerleaders after he's won the big game.
If you ignore automated worms and mail viruses, Linux/Unix has traditionally had far more attacks than Windows. Even a few short years ago, you could put a unpatched Windows box on the Internet and would be largely ignored. Not the case with something like RedHat Linux, which would be scanned and hacked within hours.
The "skript kiddies" like hacking Linux & Unix because it's "elite" and has usually has tons of tools like compilers installed. (Also, the Unix community was far ahead of Windows people with "open disclosure", which meant it was really easy to create hacks.)
Anyone else remember the t-shirt "My other computer is your Linux box". Little joke at the expense of the n00bness of most Linux users.
Oh, and RedHat already does nearly weekly security updates and has done so for years.
vtun was never designed to be totally secure. It even says so on the website. Still I admit, two years is a lot of time for someone to come up with something. Shame, cause it's a really nice program.
Anyone out there up for the challange? (I'd try, but I'd have no idea where to even start!)
One particular quote:
pretty much sums up the rest of the post.
(2,3-Benzopyrrole)
Sorry, dude, the news is pretty much out on this... per installation, *nix is attacked more than Windows.
Maybe you were on vacation or you trashed the news with the rest of your Windows virus-infected email.
BTW, troll, troll, troll.
Mods, please keep in mind that this fellow is a known troll.
c id=6995 224d =6936 234
Evidence here:
http://slashdot.org/comments.pl?sid=78966&
http://slashdot.org/comments.pl?sid=78128&ci
30 BILLION? I think not, you fucking moron. Go look up the estimated population of the world.
Many projects arent aimed at production at all and thats all dandy in my book. If every piece of open source became mysteriously secure by accident and voodoo i would be much surprised. Ofcourse there will be insecure and shoddy apps but you know what?
With open source the users can migrate without a penny to something more secure. The difference as i see it is that you can choose what authentication/web/shadowing/crypt you want by yourself and you are not in the hands of someone else. You are responsible for the security, not someone else that you just put the blame on. A frightening thought to some but a bliss to the likes of me.
I am a grown up and i can make my own decisions.
HTTP/1.1 400
What a big waste time of so Peter Gutmann found two programs that are not secure. Gotta ask your self is anyone maintaining them ? Does any one care ? There are few M$ programs that have paid programmers that aren't secure XP, w2k. Need I say more.
or: ISAKMPD
1.23 Can I use vtun over SSH ? Yes, via the port forwarding feature of ssh. Don't enable vtun's encryption as ssh does its own encryption. Also, make sure to select the tcp protocol as SSH can forward tcp but not udp. An example session might look something like this: home$ ssh -L 5000:localhost:5000 work.megacorp.com (authenticate if necessary) work$ vtund -s home_tunnel_config
Now, having said that, I use VTUN and haven't had any problems. But then again, I also have the boxen firewalled to hell and back, no services allowed but SSH from a few known hosts, no root SSH, etc. So even if you do crack my key, you're not getting much that will get you anywhere.
While I don't consider it the most secure tool, it does the trick well enough for now. Kudos to the VTUN team, and kudos to Peter for his examination.
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
"Whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls." - Makali.
http://rocknerd.co.uk
Package: libgpgme11 ...
Description: GPGME - GnuPG Made Easy
GPGME is a wrapper library which provides a C API to access some of the GnuPG functions, such as encrypt, decrypt, sign, verify,
Can I hump your skull now?
I've used vtun for years and years. It's always been a nice, easy system to set up.
I also always turned off security on it - it's primary purpose was always to be a tunnel solution, not so much a security tool. What's more, I don't open any more ports on my server than I need to - I bet there are buffer overruns in vtun...
I always tunel vtun over ssh. Problem solved.
I need to look into openvpn (http://openvpn.sourceforge.net/).
yeah but he's a really GOOD troll
http://www.slashdot.org/~greymond
Linux is only considered more secure than windows because it has less attacks.
Troll.
Your statistical analogy is based on an irrational premise. Having more or fewer Linux systems does not alter their vulnerability to attack. Security relates to design, not demographics.
Open Source or Closed Source, its just as easy to write insecure software, either way.
The point is, that with open source you can see just how insecure or secure a particular product is by looking at the code.
Open source is inherently no more secure than closed source software. The difference is people like "Peter Gutmann" can see what is wrong and be at the ready with suggestions how to fix it.
Electronic Music Made Using Linux http://soundcloud.com/polyp
uh those links didn't work for me?
Wouldn't it be less redundant to say "paragon of crypto design"?
Of course when no one applies the patches, you'll get some nasty events.
Use File::Find instead. And don't forget the -w switch!
Rating: 8.35/10.00 (Rank N/A)
Vitality: 0.01% (Rank 4941)
Popularity: 2.72% (Rank 1001)
VTUN
Rating: 8.55/10.00 (Rank N/A)
Vitality: 0.02% (Rank 2787)
Popularity: 2.69% (Rank 1017)
Neither of these projects are dead, quite, but neither is terribly active, either. Sourceforge shows one developer for CIPE, for example.
As an earlier post said, crypto demands skills which aren't generally available, in an unusual combination. Many competent eyes make bugs shallow. Many competent coders make bugfixes quick. It looks as if those packages haven't drawn the competent eyes and coders yet.
Maybe Mr. Gutman's post will draw some good folks who are able to do the work to these projects. Or maybe it will inspire the maintainers to simply let them fade away. Either way, we're better off for his efforts.
A third possibility is that folks will just not care. Gutman tells us:
This kind of thing needs to be fixed or abandoned; bad security is worse than no securitySee what I've been reading.
The main article here isn't about security packages that are uglier than dirt, it's about "security" packages that are insecure. I'm not aware of significant security problems with GPG (as long as your trust models and operating environment are compatible with its requirements and capabilities), and you appear to be ranting about how ugly it is to use. Well, we all *knew* that...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
VTun has been updated
in 2002 and 2003.
Check their homepage:
http://vtun.sourceforge.net/
Maybe only small update.
here
so whats wrong with loopback?
CIPE is junk. It isn't worth the code that is written to amke it up.
Its quite obvious what he's saying to anyone who approaches these issues with an open mind.
Two crypto tools, wanna-be PPTP alternatives, demolished. That leaves Linux with at least 6234234342372589255787895478 more.
When all else fails and the bullshit starts pouring out you ears, and you just can't masturbate ONE MORE TIME, start your stupid pathetic blathering with "Erm..." or "Umm...", and then correct the poster's spelling, making sure to use "[sic]".
... to use.
I hope the flaws are fixed.
So what does he have to say about the freeswan IPSec implementation, especially when combined with iptables?
The GNU project does not exist in order to get people to use their software. It exists in order to promote "free software." To that end, they *do not* want their code inside "commercial" (by that, I mean "proprietary") software, so the BSD license isn't a good choice.
Nobody uses PGP on windows, either. I don't think it has anything to do with licenses, but rather with the fact that it's not automatic to tell if someone (a) has PGP/GPG (b) cares and wants you to use it to send mail.
OTOH, I do agree that "open source" security stuff is pretty crappy.
You imply with your post that the security of a system is inversely proportional to the scale of the deployment of that system. I'd love to see some evidence of that.
I would like to see evidence of that too. Well, other evidence than already exists (e.g. Windows has more attacks and is more deployed...that's evidence, right?). In any case, I am not sure why this seems like some huge shock. It's not really that security is worse on OSs that are less common...it's that if you have a million boxes running one OS, and 2,500 running a different OS, if you are a hacker, which target are you going to gun for? There was an article posted a week ago (sorry I don't have the link) that said that linux web servers were more hacked than windows web servers (more evidence of the more prolific, more attacked). Though it was a bit of a questionable article, it wouldn't surprise me if it was the case. One thing Linux has going for it is its strong seperation of user and administrative priveledges. That doesn't exist on *most* windows boxes out there hence they ARE inherently less secure (there are other factors of course). Why doesn't windows do this? It caters to the ease-of-use first. su isn't a complicated concept to us, but it isn't so accepted to joe the user who would get pissed if for some reason he couldn't install his new p2p program. I can almost guarantee you, if Linux (one flavor of it anyways) gained market dominance, and they all ran the same apps (like windows office, etc) you would see a larger number of attacks that did more damage. It would have a lot to do with unpatched systems, and let's face it, when it comes to patch security holes, Windows has a better method of notifying and distributing the patches. I hope Linux will have something similar soon. In any case, an OS is an OS, use your favorite one for moral, technical, gaming, whatever reason, just don't be so defensive about Linux that you blindly accept that security is already perfect. Linux users should not be surprised to see more attacks that are more significant scale as it gains marketshare and has more comonly used apps.
Support a great indie game: http://www.abaddon360.com
Open source crypto has vulnerabilites.
Closed source crypto has vulnerabilities.
Can't these problems be solved by using STL?
One wonders how many Open Sourced OS/Apps installations are delayed or due to the FUD about security, privacy, etc. Too bad there's enough politics to prevent the protocol fixes. I suppose some open source firms need ways to differentiate themselves...
The first big difference between OSS and commercial products is often that commercial products want to either invent a new proprietary protocol, or, for marketing reasons, push an obsolete protocol as a new innovated protocol. Both of these leave end users insecure. However, since everything is proprietary, there is no way for the user to know the level of insecurity. And, if we may drop names like in the article, Scheier lists a new company nearly every month who tries to push crap as security, though he has gotten so annoyed that he has skipped months of late.
And to drop the name again, Schneier, has spent his time of late trying to convince people that security is so much more than protocols. The protocols must be implemented in code correctly and deployed correctly. Unless one is a huge national agency with a classified budget and decades of security experience, it is unlikely that one can create a secure product. It is much better to make the code public so that interested parties can investigate. It doesn't mean they will.
The two of these combine in interesting ways in closed software. There are claims of 1,000,000 bit keys. There are situation in which security by obscurity is used as the first line of defense. There are situation in which the DCMA is used as the first line of defense.
Which is just to say that conclusion #1 and #2 does not follow from the text. Just because one finds a few packages that are out of date in OSS, does not mean that finding a few updated packages in closed source software are more secure. Conclusions #3 and #4 are trivially valid, and applies to anyone writing software in any model. All programmer should take the advice to heart, especially if they want to design a right management system using closed protocols.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Uh, when the industry standard was Microsoft's PPTP implementation, they were speaking truth.
It is eminently unfair to call these "Linux" packages.
.
Of course, none of them are GNU packages, either . .
OTOH, tinc does have a linux.org homepage, but then it seems to not be "Demolished" by any reasonable definition. He says "This is a terrible way to use RSA, and usually compromises the key." and I'm no crypto geek, but I think what he means by "compromises" is "provides and avenue of attack that is mathematically simpler than brute force against the key" not "reveals the secret".
So, two seemingly abandoned projects are suspect, and one relatively arbitrary (but Open Source!) package has a theoretical weakness.
All that said, my question is: What has been demonstrated (or demolished)?
-Peter
Of course, the author of that article went on to write CIPE, which is one of the problem protocols under discussion.
I use freeswan IPsec for securing wifi. The biggest problem with IPsec is that it suffers from "committee bloat" and is very complicated to use. Freeswan partially mitigates this complexity by implementing only a narrow subset of the RFCs (in fact, it is not even RFC compliant, because they deliberately removed some required features that might compromise security).
The good thing about IPsec, and freeswan in particular, is that they were openly developed with actual expert input and nobody has yet cast any doubt on the security of either.
Good lord. If he googled a bit more about vtun he would have seen responses in defense of it, as well as asking to go beyond theoretical garbage to proving the insecurity.
He says nothing new.
The key to using encryption with vtun is to use a strong password and to change it now and then. There's really nothing wrong with vtun's encryption approach otherwise.
Any potential software issues not relating to encryption do not make vtun any less secure than, say, SSH (see the latest patches).
This guy, obviously with more than a few clues about security, is able to examine the products, right down to the source level, analyse the security provided, freely publish his findings and suggest improvements (even if all he suggests is 'scrap it', and something about skull-fucking with sound-waves.)
This is great information, and while it might not reinforce the 'open source uber alles' message, it is very useful to anyone who might be considering working on these or similar projects, as well as anyone that uses them.
Even if Mr. Gutmann says these products can't be completely fixed, at least the authors can improve them now based on his comments, and just because this guy says it can't be done, doesn't mean it is gospel.
I say a big thank you to Peter Gutmann (a fellow kiwi, alright!) for taking the time to write this and help to improve the state of open source security products.
I gots ta ding a ding dang my dang a long ling long
Check out FreeBSD 5's GBDE system. It's still relatively new and needs some polishing, but is improving rapidly. It's already quite usable.
Yeah, but....
This is totally an exaggeration. Of course the card doesn't fit in the PC-card slot. The Airport Extreme doesn't even look like a PC-card at all.
The PowerBook G4's are indeed cramped, and do not lend themselves to be tinkered with...but that doesn't conclude "tragedy of design".
The Airport card install isn't that difficult. Remove the battery, take out 7 screws to remove cover, plug in card, plug in antenna....put cover back on, and insert battery....done.
If you had read the customer-installable parts procedure, it explains it very simply:
http://www.info.apple.com/usen/cip/pdf/pbg4/pbg4dv i1ghz-apc-cip.pdf
Right, quote a 1998 report on Windows NT's PPTP waeknesses, many of which were addressed in Win2K.
On that topic, could someone suggest a good Linux-based PPTP server that can use Active Directory for authentication/access rights or an IPSEC server that works with XP/Win2K's native IPSEC client?
If you don't want to repeat the past, stop living in it.
1. Make good point that open and closed source software can both be insecure.
2. Demonstrate point by showing out insecurity in some open source software.
3. Someone notices the good point and fixes the insecure open source software.
4. Close source software gets no such notification, still has holes.
5. Point one nullified.
83: I don't know anything about crypto but my cousin uses Linux 57: Hey! Get him! He said something bad about Linux! 21: He should try the X system. I've never found any theoretical holes in it! 23: Oh, yeah? Well why don't he quit whining and write his own?? 1: Insightful, informed comment on the subject, modded to (-1 Offtopic)
It makes no sense to perform that kind of comparison between "Microsoft" and "open source". Microsoft is a company with a product line. Open source is just a license. It's not even an "apples" vs. "oranges" comparison. I mean, if Microsoft releases a broken piece of software under an open source license, does open source quality all of a sudden decrease? The question of whether there exist insecure open source packages corresponding to some Microsoft package has a trivial answer: of course.
The proper comparison is to ask whether there exists highly secure open source packages comparable to Microsoft's package in functionality. And the answer is usually, "yes".
The difference between open source and Microsoft is that among the hundreds of open source systems, people can find a collection of open source tools that is secure. Because they are open source, they tend to interoperate and use open standards, and that means that you can more easily mix and match. Users and companies can audit and verify those tools themselves if they care to, they can fix bugs that they discover, and they can share their discoveries openly. No, the open source process doesn't guarantee security, but it makes it possible.
First of all, I've got a tremendous amount of respect for Peter Guttman, and not just because he's the author of the coolest quote relating to computer security of all time (if you can't find it in that essay, you're not paying attention). But...he misses the point.
... TCP is terminated at the forwarder, addressed using SOCKS4 or SOCKS5(>3.7.0), and forwarded to the appropriate destination on the other side of the tunnel. It's TCP _only_, but it operates completely in userspace.
We do not have an effective method of running a stateless cryptosystem, but IP actually does require stateless operation. All these mini-systems that have sprouted up exist because of this.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot, and there's a bigger problem: By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.
This doesn't work very well at all -- effectively, both sockets attempt to simultaneously adjust to changing network conditions, and since neither knows about eachother, they both screw up badly.
All because we do not have a stateless cryptosystem that works. It may very well be that such a demand is impossible. Stateless cryptosystems can send a message and not only not prenegotiate a session key, but tolerate large number of dropped packets. Replay attacks need to be suppressed, but packets need to be able to survive high latencies. CPU load needs to be kept reasonable, but no message can rely on the asymmetric results of another.
In short, normal cryptosystems are built to be inflexible to attackers; we do not know how to make them simultaneously flexible for networks. The reasons why should be obvious -- anything that can go wrong on the network, will go wrong because of an attacker. So telling everybody to use SSH/SSL is ultimately code for, "We just don't have the crypto to secure IP." And we know IPSec is a failure; if it hadn't been for VPN's, it'd be as rare as multicast and a hundred times more expensive.
Solutions? I suspect short signatures will ultimately make the difference, as will better time-based protocols (at least for intra-admin-domain work.) But no matter how high my opinion is of Guttman, I cannot ignore he considers solved problems that fundamentally refuse to go away.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. There is an immediately available VPN solution that's free and doesn't suffer from TCP-over-TCP effects. Look up Dynamic Forwarding for OpenSSH
Shouldn't that be "suckland"?
No, because GPGME is GPL, not LGPL, and all it does is make calls to the (GPL) GPG binary.
Someone let me know when they've managed to crack Winrar passwords... I'm getting sick of people posting passworded porn to USENET.
[s]he has some good points!
Uh, Super FreeS/WAN? I use it over the stock FreeS/WAN because it includes the nat-traversal, Delete SA, and x.509 certificate patches. Mind you, I also prefer SSH Sentinel over the braindead Win2k/XP IPSec stacks. Here's a link to a nice howto if you insist on using Windows builtin, even though SSH Sentinel's under $60 a head.
ones-complement portion of the crypto engine fails when X=0
Some conversions for the interested, of zero into four bit binary of various types: 0000 (1's complement), 0000 (signed magnitude), 0000 (2's complement)... Uh, what was I doing again?
====
Crudely Drawn Games
It's not Macs that you hate, but your own incompetence. I would like to sympathize with you but that's beyond my own competence I'm afraid.
It runs on WinNT, too. So it sucks more.
My other car is first.
That really sucks.
I've used deslogin and cipe for years because
I hate having to patch every two months against the
latest ssh exploit.
Oh well..if this guy can bring Olaf Titz to his
knees in just a few paragraphs I guess I'd better
go ahead and look at that buggy marvel of secure computing known as ssh.
Its funny how theres always a critic who
first off can find multiple problems but
cant write one him/herself.
Anyway more power to opensource !
GPG exists to Give Users a Tool to Use Crypto. Insofar as both ends of a communication channel must both use the same kinds of crypto, crypto projects should be trying to put their output in as many hands as possible; to put it more generally, the more people who have crypto, the stronger it gets. GPG's goal should be to put GPG in the hands of as many different applications as possible.
The GPL is not a means to that end. It is in fact contrary to the project's goal, because it discourages commercial adopters.
This is yet another example of the GNU project sacrificing usefulness in favor of principles. I like that they're there, promoting their principles, but in the meantime I won't expect gpg to ever be popular or useful for communicating with the general population.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
If you don't understand why he included EE, you won't understand his point about a pseudorandom generator, or why most people have false conceptions about using it.
Cutting the post of another person to pieces because you're a jackass? +1 Funny!
Considering OpenVPN, FreeS/WAN, and TunnelVision are available, much more secure, etc. I doubt that anyone will step up to the plate for these. VTun's usable as it currently is for establishing quick and dirty SSH based tunnels- and that's about all I'd ever use it for (not that I'd use it, like I said, there's better and still OpenSource...).
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Oh lord, just when I had completely lost faith in slashdot, you restore it. I nearly pissed my pants. Thank you!
But I'm pretty sure the top paid engineers at microsoft aren't the script kiddies you see running around on this site. In fact, I'd be surprised if this guy himself hasn't consulted at one point or another for microsoft.
This is a very essential point most people never consider: Microsoft has the money to hire just about *anyone* on the planet who would be willing. And, yeah, maybe none of the linux zealot script kiddies would work (although I'm sure many would succumb to money when flashed a $1000 in their faces), most leading industry experts would. Why do you think Microsoft is getting involved so closely with Universities? Do you think it's just to get programmers using their products? Or do you think they actually intend on getting scientific reasearch collaboration?
In fact, if I recall correctly, some educational institutions have access with NDAs to Microsoft windows source code.
You don't need to mess with the users path, just drop a PGP executable ahead of the one that is in thier path... it seems like if you have the kind of debug access that would let you update a shared library you would also have permission enough to drop something in /usr/bin or the like!! Or perhaps enough permissions to just overwrite the original PGP with a wrapper script.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Apparently your posting strategy went something like this:
Ironically, your post made for the better demonstration of the problems inherent in the Slashdot moderation system.
Do you have any idea at all what he was talking about? Lots of cryptographic algorithms depend on random numbers. A common mistake by newbie cryptographers is to use a pseudo-random number generater which gives predictable values, leading to encryption which is easily broken. Real cryptography software must work very hard to find sources of unpredictable randomness in a system (like, say, the timing of a sequence of keypresses, if the computer has a keyboard). He was making a good point.
Do you even know what ones-complement is? Again, he was making a point, but either you intentionally ignored it for the sake of your reply or if flew right over your head.
He made a good point: If a programmer produces a buggy game, it's not a big problem, even if millions of people play it. But if a programmer produces a buggy cryptography library, and millions of people use it, that IS a problem.
Wow - criticizes someone else's post without having a clue what it means! +5 Funny!
A lot of people are trying to defend OSS development processes against the article author's comments. You just happened to be nearby.
1) These holes are far less likely to be in the base operating system implementation, as the OSS mantra is generally to put as much logic in user-space as possible.
And this has absolutely nothing to do with anything.
2) These holes won't be covered up and released only after the vendor has decided to let us know about them.
Closed-source holes aren't covered up anyway; if someone wants to talk about them, they get talked about. OTOH, you could claim that CIPE's holes were covered up, since the CIPE team obviously didn't release any information after they were notified 2 years ago!
3) These holes will be fixed up very quickly (in general, anyway), in individual patches or point releases, without onerous licenses attached to them, and without fear that the release might break the rest of my operating system.
This is precisely the kind of idiotic hand-waving that the article was about. These projects were not fixed up quickly, or at all for that matter!
4) Because OSS products use open standards, if one particular package is simply too insecure, at least I can change to another product and have things interoperate (eg, switching from Sendmail to Qmail/Postfix/MTA-de-jour).
CIPE and vtun use open standards? Bullshit.
Using ftp.ssh.com version of ssh:
This way, you get the security of ssh with the convenient P-t-P interface of vtund.
Problem solved.
You want security, just display your secret text in the Symbol font.
On that thought I was paid by work to look over sudo. I looked through it, declared it safe and the very next day there was an upgrade for buffer overflow conditions. Many eyes travel the first half carefully, then get bored. Start at the bottom and work backwards.
OK, now tell me an easy way to roll this out to 20+ lawyers home machines without paying a home visit or having them bring in their machines.
I can give them a quick HowTo to set up a PPTP connection to the current Win2K server I'm trying to get rid of, they can handle that. But installing a custom IPSec client, running MSC and importing certificates? No way.
If you don't want to repeat the past, stop living in it.
Funny, I looked all through the Linux source code and didn't find any of these packages, then I went to their sites and all of these packages run on multiple hardware and software platforms, including windows with cygwin installed.
So... where did these fellows get "Linux" from?
Well, I'll tell ya... first you have one microsoft employee write up an article and post it someplace on the web... then you have another microsoft employee post a "news" item onto slashdot and wait for it to be posted.
These are not now, never have been and never will be "Linux" security packages. They stand or fall on their own merits and failings and have _nothing_ to do with Linux.
Why would someone do such a thing? Well, they work for MS and MS just had 100 million virus and worm infections, from the exact same hole that the last 6 viruses have all exploited, so they have to tear down the only other OS that is gaining on them, Linux.
Quick Quiz: How many viruses has Linux ever had? Why none. How many servers did the most successful internet worm ever infect? Why less than 5,000. How many web pages have been hacked by defacers on Windows sites? I can't count that high. On Linux sites, less than 20,000 ever.
Personally, I run OpenSSH. (Notice that I did not say Linux OpenSSH.) Although I do wish that they would carefully audit their code base to eliminate all buffer overuns once and for all. And then reaudit the code base before accepting any checkins to ensure that no new buffer overruns get introduced.
It is easy to pick out 3 projects on the net that are being developed by a small group of people, or even one person who is still learning, and who has not yet learned how to attract the support they need from the community. Either from their own inexperience or through personality problems that make it hard for them to work with others. It is easy to pick out these projects and belittle them. but the thing is, the stronger the ecology of things out there then the harder it is to exploit everything. Sure there are weak protocols, but if you look, almost nobody uses them. Strong protocols like openssh and lsi are in use by millions of people.
These protocols serve a very useful purpose, as teaching aids on how _not_ to implement a security protocol. I am sure they also got a few thing correct as well.
And the 2 people trying to talk to each other are _always_ Bob and Alice. The person _always_ trying to easedrop is Eve. This is security 101.
In my studies of security issues, I keep seeing the same themes over and over, and the same failings over and over. It would be interesting to develop a security framework that everything else plugged into, so that the parts and pieces could be individually upgraded without the rookie mistakes made by accidently pluging things in the wrong way. This way you could implement a new block cypher and just drop it into the framework. The framework could use it correctly, because it knows how to securely use a block cypher. Same way with all the various parts and pieces.
And I am sure that each of these 3 packages that were criticize unjustly got some things correct as well as the few things wrong that were noted.
In the newer protocol the key is renegotiated every few minutes.
Chris Morris is a genius. Check out "The Day Today" and "Brass Eye" for inspired and disturbing media satire. Check out his radio show "Jam" for inspired and disturbing um... er... stuff...
"In "Brass Eye" Chris Morris managed to produce what is easily the most explosive and challenging comedy series yet seen on television. Co-written with Peter Baynham and co-produced with Caroline Leddy, each episode was structured as a serious documentary, only the centre of its study was a plausible but completely fabricated source of media panic, from killer drugs to plans to 'get tough' on young offenders. To add weight to the glorious fabrications of "Brass Eye", Morris undertook innumerable interviewer disguises to persuade dozens of publicity-hungry celebrities to decry the damage that was being done to society.
One such individual, MP David Amess, was so totally taken in by the 'rise' of a non-existent drug named 'Cake' that he brought the matter up in Parliament. This sparked a wave of panic inside Channel 4, who pulled the series from its intended November 1996 transmission slot for 'further consideration'. A concerted campaign by Morris' fans and his many admirers in the media ensured that the series resurfaced in early 1997, although by then it had been tainted by Channel 4's uncharacteristically cowardly editing. Debates over cut material raged right up until each actual transmission, and a last-minute spat over a sketch intended for the final episode resulted in a caption card likening Channel 4 head Michael Grade to a moist area of the female anatomy being inserted in its place."
Cook' d and Bomb'd
This is open source, figure out where to submit your patches or else you are nothing but an arm chair security expert.
Absolutely absurd. I can't believe you wrote this. People who are good at writing code donate code to free software projects. People who are good artists donate art to free software projects. Yet, somehow, when a noted cryptographer does a (somewhat acerbic) security analysis of *three* open source packages and lists fixes, somehow you feel that he hasn't contributed anything.
Incidently, I'm curious if you're aware exactly how much it would cost in consulting fees to get someone like him to sit down and review a given product. This guy contributed a lot more in terms of intellectual value to those three projects than the forty-five people that sat down and wrote five-line patches to remove gcc warnings (not that their work isn't appreciated, but still).
He deserves our thanks, not scorn.
May we never see th
Make your home visit and install remote management software. It'll be a significant savings in the long run, regardless of whether it's relevant this time or not.
May we never see th
1. You assume (thinly) that the best (in any field) will work for microsoft.
Pretty hard to quantify the "best" person in cryptography, but you could probably get a list of the fifty or so best-known players. I suspect that most of them would be more than happy to work with Microsoft. My own experiences say that even that folks that are generally dislike MS practices aren't willing to throw away a good contract to work with them. It's only the most extreme fanatics -- RMS might be willing to do so, for instance, but he's definitely the exception to the rule, and a radical.
2. You assume that "Microsoft" listens to the "best" and does whatever they recommend, regardless of the consequences.
*Snort*. This is true of any company. Plenty of good engineering advice gets ignored. Same thing happens on open-source projects, for political or NIH or what-have-you reasons.
3. You assume that MS will take suggestions from edus when the edu finds something of note in the MS source.
Depends on how significant it is. If it's "we can break the VPN you're billing as secure badly and trivially, then yes, MS will act. May take some PR exposure, but they'll do it.
Two of the mentioned OSS projects so far have not taken action, it's also interesting to note.
May we never see th
I felt I should fill Peter in w.r.t. IPSEC and the amazing FreeS/WAN implementation thereof. I sent him the following by PGP-signed E-mail (cut-down for posting):
I'm sure you've received a million replies to your message now that it has been Slashdotted, but for the record, please use IPSec for your VPN needs.
[...]
Sure, there are OSS *nux programs that attempt to implement the protocol, mostly to connect to MS servers that only support it, but the *real* player in the VPN world is the IPSEC protocol.
[...] IPSEC inter-operable and standardized but it has an *amazing* and well-maintained Linux implementation. FreeS/WAN, from http://www.freeswan.org, is very well documented, well-maintained, and written by people with a wonderful level of attention to security.
They may not be perfect, but I've been watching and using the product for years now with very good success. [...] the project is now moving forward with 2.2.x, 2.4.x and 2.6.x Linux kernel compatible versions.
- Michael T. Babcock (Yes, I blog)
Do someone know if yavipin ( http://yavipin.sourceforge.net/) has similar security problems? The author claims he made it after a security analisys of vyun, tinc and others. Looks like it's been abandoned though.
Comment removed based on user account deletion
"The fix for this is to scrap the key exchange portion completely and replace it with an SSH or SSL management tunnel"
that even those protocol contain flaws every now and then, thus for example we use those ontop of cipe or openvpn like mechanisms to achieve double layering in cases were even ssh cannot be fully relied on. And don't I feel good about doing so now. Sadly cipe needs quite a bit of repairing it seems.
Fabulous article nonetheless.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
FreeS/WAN isn;t in the stable kernel yet (i heard it was integrated 2.5 tho), but the BSDs have solid IPSec implementations already. Why would anyone use some lousy user space crypto thingie with more bugs? VPN tunnels with Windows? Maybe. And then again, there is OpenVPN.
You are not supposed to RTFA, this is /.
Enig? Det alt for hot det smor!
While I deeply respect Peter's analysis, I do recall that many years ago he distributed open source implementations of strong encryption libraries only to subsequently produce new and improved versions but with a price tag attached.
I think, therefore, that it is a little unfair for him to merely criticise open source implementations whose authors wrote the software for the public good. Instead, Peter might want to re-think his decision to move away from the open source community and contribute some well-engineered software to it, in order to plug these holes, rather than exploit his undoubted talents purely for commercial reward. In any case, as I recall, he holds academic tenure. Morally, contributing solid code to the open source world would, in my opinion, count for more than mere criticism.
Peter Gutmann contacted us (the tinc developers) on September 15th, quoting the part of his writeup relevant to tinc. We exchanged a few emails since then. There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible. He still hasn't convinced us.
In some more detail: the 32 bit predictable IV might make the other 32 bits of the first encrypted block more vulnerable, but the other 32 bits of that block only contain part of a MAC address which does not reveal any important information. It does not compromise the other blocks AFAIK, and in fact a sequence number instead of an unpredictable random number is more secure according to Jerome Etienne, who has done a much more detailed security analysis of tinc in the past.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
Peter Gutmann also believes tinc has to be configured identically on each endpoint, but that is not true at all.
We're still in discussion, and if we believe there is really a problem we will fix it. In his conclusion Peter says that everyone should be using SSL or SSH. We could, but I don't believe SSL is necessarily the be-all and end-all of encryption.
You're right.
Another problem, particularly for U.S. programmers trying to find some feedback and multiple eyes looking at their pre-alpha not-on-sourceforge crypto package is: How? If I've created something intended to make it really easy for people to exchange encrypted emails, what's a good way to get it out there that won't run afoul of the crypto laws? It's not like programmers from the land of the free can freely put their crypto code on sourceforge for critique.
Yeah, I've spent many many hours reading and re-reading the EAR export regulations trying to figure out how to exchange crypto software with others on the net for academic purposes without being eligible for being thrown into camp X-ray indefinitely, and I can't make heads or tails of it.
/dev/random is not pseudorandom.
/dev/random is fed by a good source of raw stochastic randomness along with other nondeterministic system events into a pool of entropy which is stirred etc. etc.
/dev/random BLOCKS until it can generate enough entropy to be above an acceptable threshhold. Practically speaking, the user can bang away on the (local) keyboard if necessary to generate such randomness.
/dev/random. You don't create a whole device to just recreate rand().
Ideally
If you don't have a good source of raw stochastic randomness (like thermal noise in the intel 8xx chipset or freewheeling oscillators in the new via CPU), then
This is, of course, the whole POINT of
------
But yes, good crypto is HARD to write and HARD to identify flaws in. This obvious fact seems to sometimes escape cryptographers when they review inexpertly created crypto software, who lament endlessly that people get it wrong, and sometimes get sufficiently exasperated to even identify the flaws in comprehensible terms. "This code listing should be self explanatory" being a key sin here.
It's good that someone keeps after 'hobbyist crypto' authors to point out that their stuff is dangerous though. Is there a good communications outreach channel from the crypto community to the general programming community about the dangers of inexpert practice? I'd imagine a website dissecting a few projects in detail could drive home the message: If you don't really know, you're going to do it wrong.
-josh
Why write new protocols that are doing the same thing that SSH is doing? It's nonsensical.
Show me how to forward UDP traffic over SSH.
Vtun isn't "the same thing", and indeed has its uses. Discard vtun security features and wrap it into SSL, and you have a nice, secure, generic IP tunnel.
I'm willing to bet that the guys behind these protocols got flat-out laughed at by anyone doing real cryptography work, but still somehow felt that they were right all along.
They made a honest attempt and failed. Never bet on what other people feel.
Lisp is the Tengwar of programming languages.
I can only speak for vtun here, but from my expiriance, setting up a VPN for your first time is a bit rough.Hell, even when you've done it enough times that you know its caveats and snaffus like family, its still kind of a mean old hag of a bitch. VPN is a fairly complicated issue, and vtun seems to exist to simplify it for the masses. Except that a) the masses don't need vpn's, and b) they made a simple solution to a problem that requires a fairly complex answer and got an essentially wrong answer that provides no real protection.
Vtun was recomended to me by a friend, and upon using it, I feared that it was, quite frankly, far too easy to setup to be effective. You don't need to know a whole lot about networking, encryption, security, etc... to use it, and I feel that approach makes the entire package weaker, and sets an upper limit to just how effective it can be. Sure, zone alarm is easy to set up, but is it pf? is it ipf? Hell, is it iptables? Not at all, of course not.
The other one, I can't speak on, I'm not qualified, and despite this being the interweb, I refuse to pretend I know anything about it.
not spellchecked because work was awful, and I am going to bed....
--Nuintari
slashdot : where an opinion can be wrong.
> What's even worse is that some of the flaws were > pointed out nearly two years ago, but despite the > hype about open-source products being quicker
> with security fixes, some of the protocols still
> haven't been fixed.'
The potential for fixes is there in the open source community - but someone has to care enough about the product and the fix to actually work on it.
Take a look at the bug database for some of the large bodies of software. Typically there will be quite a significant body of defect/bug reports . The projects I have seen have the defects broken down into the majority awaiting classification, then a lot of closed reports (either due to the problem being fixed, non-repeatable, or wrong/incomplete) and the rest awaiting someone interested or bored enough to deal with them.
Doesn't seem to matter whether the software is commercially supported or open sourced. I recall a time when one popular workstation vendor shipped a version of the sort command which turned lines longer than a 1000 or 2000 bytes into two or more lines. After repeatedly having the bug reported to them, they 'fixed' things by documenting in the man page this behavior...
Note that the fix for the problem had been available in the open source community since near the first report...
URL: http://xanga.com/lvirden > Quote: Saving the world before bedtime. Even if explicitly stated to the contrary, n
By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.
I'm not sure I understand. There may well be no good solution for situations like DNS where data is transferred in short, Poisson distrubted bursts, but why should it be so hard to work something out for long streams of isochronous data. You could negotiate key exchange over a TCP control channel and send the data in in UDP packets with encrypted/signed payloads using the key negotiated over the control channel.
Of course, this is exactly the kind of thing that's hard to do well, I suppose, so I'm probably missing something. Writing cipher code is fun and easy, writing crypto protocols very hard.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
>It's possible to create insecure "security" products just as readily with open-source as with closed-source software.
I'm guessing that "Peter (sigh)" is thinking of "product" in the sense of "n 1: commodities offered for sale".
Thing is, I don't work on open source "products", I tinker with ongoing projects, in the sense of n 2: An undertaking requiring concerted effort, and I do so for my own pleasure, not for "Peter (sigh)"'s benefit.
When I start selling you my project as shinola, you can tell me that it's a shitty product. Until then, you're welcome to contribute. If you just want to criticise, then I'll thank for your input, but advise you to calm down and take a chill pill. Anybody using my project is liable to be doing so because they enjoy playing with it as much as me, not because they're relying on it for a critical application.
If you were blocking sigs, you wouldn't have to read this.
The only way that the argument for open source software security holds water is when its security is vigorously pursued by a very active developer community such that a hacker must be able to see and exploit before, at bare minimum, a handful of qualfied experts can detect, fix, and efficiently deploy patches to the more dilligent end users. In other words, it's a race against time and a numbers games in which the deck is hopefully stacked against the hacker. However, if that open source community cannot even be bothered to hunt, fix, and deploy patches for well known vulnerabilities, then this same openness makes it that much easier for the hacker.
Peter just demonstrated a case of this apathy. My gut tells me that this the rule, not the exception. The core linux kernel, apache, and perhaps a coupe dozen others are the few projects that can claim a truly active developer and security community. I, for one, wouldn't trust any of the other open source packages for any computers that I deemed critical insofar as security goes.
How easy would it be to replace CRC-32 with
something else in CIPE?
Without looking at the code, I assume it does:
UINT2 word = Crc(buffer);
So could this just be changed to:
UINT2 word = Md5(buffer) & 0xffff;
And this has absolutely nothing to do with anything.
And you have no idea what you're talking about. Holes in user-space can be insulated from the rest of the system in many ways.
1) You can reduce the privileges of the daemon/user-space app such that an exploit in the app doesn't necessarily result in a root exploit. This is the technique Qmail uses.
2) You can run the apps in a secure 'jail' (UML, FreeBSD jails, etc). This is used quite frequently to enhance the security of Sendmail, Apache, etc. No, not replace security, enhance it.
However, if the hole is in your kernel, you're screwed... there's no way to insulate the kernel from itself.
Moreover, if the hole is in a user-space app, it's easily patched, and the daemon restarted. If it's deeper in the OS (ie, in the kernel), the fix is typically far more invasive and will likely require a reboot to take effect, something which sysadmins are loathe to do. How many service packs have you installed that required a reboot to take effect?
Closed-source holes aren't covered up anyway;
Again, you're misinformed. It has *very* often been the case that organizations are made aware of security vulnerabilities in their software, and that organization chooses not to release the information to those who need it. Microsoft is the most obvious example of this... there have been many stories on Slashdot about individuals who have reported security holes to MS only to have their discovery covered up, or only released to a special, select few, which happen not to be you and me.
OTOH, you could claim that CIPE's holes were covered up
Fine, one friggin' example. Would you care to tell me how this *one* example can possibly speak for the whole of OSS? In my experience, this sort of behaviour is *definitely* out of the ordinary, and means I probably shouldn't use that package. Big deal, I'll use something else.
This is precisely the kind of idiotic hand-waving that the article was about. These projects were not fixed up quickly, or at all for that matter!
Which is why I said "in general". If there's a hole in, for example, SSH, Apache, Sendmail, Bind, wuftpd, the Linux kernel, a fix is available *very* quickly (typically within 24 hours). Sure, there are some exceptions where maintainers aren't diligent enough. But I would argue that this is the exception rather than the rule... feel free to try and prove me wrong. You'll probably have trouble, though.
CIPE and vtun use open standards? Bullshit.
Oh please, like two examples defines the whole. What about standard SMTP, FTP, HTTP, SSH, SSL, or IPSec? Those look like open standards to me.
I just read an article in Linux Journal about using vtun over an SSH connection. Is it possible that this combination would fix some of the problem?
--Somewhere there is a village missing an idiot.
CIPE doesnt run over tcp, it runs only over UDP, and there are 2 "versions" one that uses a static key, and one that uses a static public-keysystem to exchange a dynamic key which is used encrypt the packets.
Are UDP not stateless?
I run CIPE, but now i'm gonna read his article, and see if i change my choice of VPN.
JonB
The article says these code fragments "speak for themselves". I'm very confused, what is wrong with them?
void encrypt_chal(char *chal, char *pwd)
{
char * xor_msk = pwd;
register int i, xor_len = strlen(xor_msk);
for(i=0; i < VTUN_CHAL_SIZE; i++)
chal[i] ^= xor_msk[i%xor_len];
}
[...]
void gen_chal(char *buf)
{
register int i;
srand(time(NULL));
for(i=0; i < VTUN_CHAL_SIZE; i++)
buf[i] = (unsigned int)(255.0 * rand()/RAND_MAX);
}
Ordering issues and dropped packet management are what you're missing. SSL and SSH get it for free by running over TCP.
Is a dropped packet an attack, or a normal error? It's nontrivial to know.
--Dan
In my rush to punch that in, not only did I mix up /dev/urandom (less secure) and /dev/random (more secure), but also forgot that urandom incorporates some degree of entropy as well. Fortunately, I was only bitching and not relying on my spotty memory for anything critical. </embarrassed>
... to the original article. It's available here .
To sum it up, he speaks good things about both Free S/WAN (representing the IPSEC-is-good camp) and OpenVPN (representing the IPSEC-is-too-complex guys). Too bad neither one run on kernel 2.0 (still my preferred for security applications).
Like the original article, very well written and informative. A must read.
Best Regards,
Durval Menezes.
I have never met a computer that didn't like me.