Slashdot Mirror
Microsoft: As of October, 1024-Bit Certs Are the New Minimum
way2trivial writes with this snippet from Information Week about a warning from Microsoft reminding Windows administrators that an update scheduled for October 9th will require a higher standard for digital certificates. "That warning comes as Microsoft prepares to release an automatic security update for Windows on Oct. 9, 2012, that will make longer key lengths mandatory for all digital certificates that touch Windows systems. ... Internet Explorer won't be able to access any website secured using an RSA digital certificate with a key length of less than 1,024 bits. ActiveX controls might be blocked, users might not be able to install applications, and Outlook 2010 won't be able to encrypt or digitally sign emails, or communicate with an Exchange server for SSL/TLS communications."
System have the ability to go further, why not make 2048 the minimum? Does anyone know why 1024 was selected? I would guess it has to do with some backwards compatibility with something. Some of the issuers are making it next to impossible to go below 2048.
just because it is closed source doesn't mean people can't read the source. thousands of universities and government agencies and even other organisations have access to the source code for windows for development purposes, security evaluation purposes and research purposes.
TechRepublic noted this a while ago and provided detailed instructions on how to work-around the issue.
"Maybe this world is another planet's hell"
Aldous Huxley
Wouldn't be much of an OS if it didn't have a reach-around.
Did you oversee Debian's SSH build when they fucked it up?
I did. I'm sorry, but that week the NSA check came late, so I wasn't able to make the compromises less obvious.
They paid up later.
No matter how few people actually read through the Linux kernel code, it's sufficiently open that blatant backdoors are not going to be inserted.
Open source suffers from quasi-religious stuff too, as you just demonstrated with your claim. Ken Thompson, of Bell Labs and Unix and C fame - the "K" in K&R, demonstrates the insufficiency of being able to read the source code.
http://cm.bell-labs.com/who/ken/trust.html
Do you oversee Red Hat's build servers? Did you oversee Debian's SSH build when they fucked it up?
Thanks for so clearly spelling out one of the great advantages of the Linux ecosystem. Namely, that a vulnerability in RedHat isn't necessarily a vulnerability in Debian so the damage doesn't propagate to the overall community of users. That's one of the great things about there being so much diversity and unique approaches to Linux. Again, thank you and I commend you on your evangelism of Linux. People need to know!
That many institutions have access to MS Source Code is kinda like instituting a needle-inna-haystack search.
Yes you might find a needle, but unless you're a needle-collector or perhaps a seamstress what in this universe d'you think you're gonna do with it?
At least with Open Source you can
(1) fix the problem with the code
(2) submit the code back to The Author
(3) expect that The Author will either accept the fix as is or perhaps integrate the solution with more elegance
Sure not *always* but the expectation would be more-often-than-not your fix (in one form or another) reaches the wider community of users.
You also fork the code and encourage people to download the fixed version, or to use your patch against the official sources until the upstream realizes the significance.
Digging through a small patch to ensure it's not overtly malicious is actually pretty easy.
Nice weasel word there. Blatant. What makes you think that if there are backdoors in Windows they're blatent?
Think back to the AARD code, they went way out of their way to obfuscate it. Microsoft would not be so stupid as to put a well commented backdoor in there.
Of course, I'm sure someone will bring up the NSAKEY incident, which various security researches (such as Bruce Schneier) have dismissed as merely allowing the NSA to install their own key to be install for their internal systems without having to have MS sign it.
You do know that backdoors have been inserted into Linux distro's in the past, and some of them took a great deal of time to be discovered. Then of course, one never really knows if a security vulnerability is intentional or not (on any platform).
There have also been some near calls as well in the kernel itself. For instance, who remembers this doozy?
http://www.securityfocus.com/news/7388
Yes, it was caught, but not because of "many eyes". It was because the attacker chose to try to modify the version control file directly. Had it gone in by some other means, it may not have been caught at all.
If you need web hosting, you could do worse than here
Not true when kernel.org itself gets hacked.
On the contrary. Which distros actually compiled and released a version of the kernel that was compiled from code downloaded during the window this attack was in effect? If you're running Debian then your kernel is anywhere from just now old to 2 years on the stable version. And if you're doing the right thing and using Ubuntu LTS releases instead of the beta interim stuff then it's the same deal. With Windows, there's only 2 releases to the mainstream. The server and the desktop versions. So whatever kernel MS builds, that's the one everybody uses. With Linux even with kernel.org getting hacked, you have a fighting chance but with Windows, you're done.
The website was hacked. The Linux source was not compromised.
They present a version of the source code. How do you know it is the version that ships with every OEM and in every COTS box?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Closed source doesn't prevent from disassembling windows functions or testing through a kernel debugger. Open source = easier to see find backdoors, easier to find security vulnerabilities. It's also easier to take legitimate code from the OS modify it maliciously and distribute the binary. In other words being open can work for you and against you. The good guys have an edge, but it's wiped out by edge bad guys get. Closed source it's harder to find backdoors and it's also harder to find security vulnerabilities.
I don't really understand how anyone can care whether a closed source operating system is secure.
This is so much garbage.
Opensource systems have their share of holes, and the idea that there is a gigantic pool of people qualified to catch backdoors in something as relatively simple as a web browser-- let alone an OS-- is absurd. Just because you can look at the source doesnt mean you can do a remotely competent job of auditing it; and the idea that a single person could somehow audit hundreds of thousands of lines of code for security "on a whim" is even more absurd.
There are a lot of benefits to open source, but sometimes its advocates really stretch the imaginations with some of the claims and accusations they level against proprietary software.
it's sufficiently open that blatant backdoors are not going to be inserted.
So I suppose the whole potential IPSEC backdoor in freeBSD thing was just my imagination, then?
Youre talking nonsense. Consider that OpenSSL is widely considered a horrendously complex pile of spaghetti code, which I believe has had its share of security issues, and yet we still use it. Is it because we're lazy? No, its because sometimes some of this security stuff is phenomenally complicated, and it would take a horrendous number of man-hours from incredibly talented people to refactor or replace it.
One of the benefits of paid software is that, if theyre competent, they can devote a lot of time to it because they are paid. Im gonna go out on a limb here and say that one of the biggest helpers to good code in a lot of OSS projects are the paid volunteers, not the mere fact that its "open" as if that dash of pixie dust makes a project magically better.
Not true, I heard many people were able to download the source code since then ;-)
Tomorrow is another day...
The "K" of K&R is wrong.
"K" is Brian Kernighan. You know, the Brian Kernighan of "The C Programming Language" fame. He wrote a book or two. He's quite famous. Maybe you've heard of him.
Look it up.
Grandpa: My Homer is not a communist. He may be a liar, a pig, an idiot, a communist, but he is not a porn star.
But nobody else has completely blocked 1024bit keys.
As everyone moves to 2048 bit keys
Palm trees and 8
It doesn't take "a gigantic pool of people qualified to catch backdoors" to fix software bugs. If it did, closed source projects would be inherently hoplessly doomed security wise. What it does take is a few or even just one qualified person to catch backdoors. For closed source, the lure of money is usually enough to hire qualified people to do the job, presuming the owner of the code cares to offer such a lure. For open source, the idea is that statistically, there's such a gigantic pool of people out there interested at all with the code that presumably a few qualified people will be in the lot and find the backdoors.
Not so much "on a whim", but there's been multiple security audits by researchers from different universities, often in testing automated code checkers. The same presumably happens against Windows code too, as MS offers access to source code to universities for presumably the same reason. Having said that, it's an actual known when it's done with Linux because there's no NDAs to hide any of the source or otherwise hold back the results from public scrutiny. And probably just as important, it might take a competent person to find the bug, but it often doesn't take a competent person to fix the bug--in part because often researchers spell out the fix. Yet, MS is the only one can fix their bugs--short of some potentially nasty reverse engineering--while there's a gigantic pool of people who can fix the open source bugs.
Well, it's not much of an accusation to point out that Oracle and Adobe frequently learn of security vulnerabilities and seemingly sit on them for months or even years, with no reasonable possibility of anyone else offering a fix--again, short of some nasty reverse engineering. Meanwhile, as much as open source bugs have been discovered, announced, and a few times ignored, the barrier is a lot less as a point to fixing such bugs with open source--with some exceptions on the complexity of reproducing the needed build environment, at times.
You mean OpenBSD? And you notice that it's still only potential-at least, AFAIK--with no code audit so far showing any evidence of a actual backdoor? Meanwhile, in Windows world, if one of the developers on the MS IPSEC code was paid by the FBI, would MS tell us about the potential IPSEC backdoor, would MS do a code audit, would we be aware of that code audit, and would MS bother telling us everything looks okay? You see, as horrible as the whole situation might be with the potential OpenBSD's IPSEC backdoor, the fact that we know about it gives us the option to audit the code or to outright avoid the code because we know of the potential threat. Meanwhile, it's much harder to trust that a corporation, which has a vested interest in keeping as quite as possible about potential vulnerabilities as it risks their bottom line, will be open about the risk to their customers. Sometimes they try to rationalize it within the scope of "responsible disclosure". But it's only really responsible if one presumes that (a) users must use the relevant code and (b) not revealing
Eurohacker European paranoia, gun rights, and h
There is an entire collection of root certs in your browser that are all trusted unconditionally. Hundreds of them, in fact. These root certs have signed thousands (who knows how many, really?) intermediate certs. All of these intermediate certs are trusted unconditionally to authenticate any SSL server whatsoever. It's pointless to have a key longer than the shortest intermediate cert key length in use anywhere. When you use SSL, you are trusting thousands of unknown parties with absolute cert-signing authority. SSL certificates are known to have been used for explicit man-in-the-middle purposes: Trustwave sold root certificate for surveillance. Sure they revoked that one key because of the bad publicity, but it's common industry practice. How is SSL hopelessly broken? Let us count the ways.
It may sound absurd, but reality is sometimes like that. A large portion of the vast pool is called "students" and the more qualified deep end of that pool is called "graduate students", and many thousands are looking at open source software from all angles for their own benefit.
That particular one came down to code standards and review. There's a reason why most coding standards explicitly disallow assignment inside a conditional structure. It's a security hole waiting to happen, just like null-terminated buffers or processing unsanitized input.
NASA's guidelines, for example, are fairly stringent. An attack would have to be very sophisticated, where the attacker would have to know the system fairly well, and insert seemingly-innocuous code in multiple places. It's harder to attack NASA because a lot of their systems are hidden behind obscurity and contractor diversification. That, and there's nothing to be gained by hacking them. Their standards exist more to prevent careless bugs from creeping in (which is really just a less-glamorous term for "security hole"). But for software like the Linux kernel where the system is completely transparent and then some, doing proper code reviews and strictly enforcing standards is absolutely necessary.
It's also a good reason to not trust binary blobs. But then again, nobody'd be dumb enough to mix their secure system with their gaming system, right?
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
True. ECC is definitely the way forward. NSA has already switched all their systems to it and the DoD mandated that all systems must switch from conventional public keys to ECC by 2010 (2 years ago). Whit Diffie said that NSA insiders told him the same thing (i.e. they trust ECC more). This has lead some to speculate there is an unpublished (NSA discovered) weakness with RSA (a speculation which may have some merit according to James Bamford, who in his infamous Wired article claims NSA "made a huge breakthrough in cryptanalysis a few years ago." Bamford didn't give specifics because his contacts didn't give specifics, but it seems much more likely they have broken RSA than the much more difficult AES (breaking RSA would give you the keys to the AES kingdom since AES keys are protected by RSA in hybrid systems like PGP/SSL. Break RSA and you have access to the AES key underneath).
It's all speculation about RSA having flaws. Maybe NSA broke AES instead. Maybe they broke both. Maybe they have "broken" it in the sense of a novel side-channel attack. Maybe the insiders lied to Bamford for disinformation purposes. We don't know. Either way, ECC is better all around due to its reduced key size and at least as strong security. The problem is even though it is in the OpenPGP standard, it will not be in widespread use for many years yet. Werner Koch, the lead developer of GNUPG, says it will take many years for it to become widespread due to all the legacy systems, old software, people not upgrading, etc. There are many software implementations of OpenPGP, and not all of them will include ECC at the same rate. Plus lots of people have RSA keys with lots of signatures and they aren't going to want to go through all of those key signing parties again.
Certainly noone would accuse Google of hiring slouches.
No, but I would accuse them of having hiring practices that discourage creativity (even if their employment practices promote it).
I interviewed with Google a little while back. Right at the start I told them I was not interested in the job they were offering as it's somewhat "below" what I currently do (and would require moving to a more expensive city for a similar level of pay as what I'm on now). They said they'd like to interview me anyway and perhaps after that offer me a job that would better fit my skills.
The short version is that after going through their rather long and drawn out process, involving mind-numbingly boring "solve this well known algorithm problem" questions, they offered me the job that I said I didn't want. After I turned them down, they then sent me a letter saying that "after consideration, we don't think you're a good match for Google".
Personally, I would've really liked to work there. But NOT as a code-monkey on their generic sites. I'm a pretty good developer (although by no means brilliant); but where I really shine is creating new things from scratch. I'm an ideas person with the technical aptitude to put the ideas in to practice. Their hiring process showed me very clearly that they had no interest in my creativity and only wanted someone who can churn code, find bugs, and patch systems to keep them running (all important; but not the only thing in the world; and definitely not for me).
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
That won't work. You don't know how they built, which compiler version they used, etc. A mismatch is almost 100% certain and in no way indicates that the same code base wasn't used to build it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Up to a point fragmentation or variety is a good thing. And not just in software. In agriculture, if your field consists of only one crop, your goose is cooked if there's an outbreak of a plant disease. A country whose GDP comes from a single source, say oil or a single cash crop, is also more vulnerable to price fluctuations in the global market. A crash in the prices of that product would lead to a crash in the country's economy as well.
Too much fragmentation of course is bad. But as far as Linux, the major distros are quite few, namely, Ubuntu, Redhat, Fedora, Debian, and possibly Suse. It's their derivatives that give the impression of excessive fragmentation. Derivatives tend to be compatible with the mother distro at least as far as the installation of third party programs not in the main repository. A binary-only printer driver that can run in Ubuntu would be compatible with Linux Mint for example.