OpenSSL 1.0.0 Released 105
hardaker writes "After over 11 years of development since the start of the OpenSSL Project (1998-12-23), OpenSSL version 1.0.0 has finally hit the shelves of the free-for-all store."
This discussion has been archived.
No new comments can be posted.
OpenSSL 1.0.0 Released
Related Links Top of the: day, week, month.
A good supervisor can step on your toes without messing up your shine.
You insensitice clod... (Score:5, Funny)
Re: (Score:1, Informative)
insensitice
You insensitive clod! My eyes hurt from reading that misspelling!
Re: (Score:1)
Re: (Score:3, Insightful)
Or monkeying with the random number generator.
Re:You insensitice clod... (Score:4, Insightful)
Or monkeying with the random number generator.
After being ignored by arrogant dolts who didn't bother to correct him and guide into providing a better fix.
Re: (Score:3, Insightful)
Then if you neither understand the code nor understand the effects your changes make to the code, you don't make the change. The fault squarely lies with the idiot monkeying around in places he shouldn't have.
Re: (Score:1, Flamebait)
Not going for flaimbait but I guess you also forbid Ubuntu as well?
And security bugs caused you to drop OS's, I am sure you dropped Windows as well.
Actually, what do you allow for production servers? I guess it is a BSD only enviroment - assuming they have never had any security bugs.
Or do the other linux distrubtions hold a perfect secrity bug track record now?
Re: (Score:2)
Then if you neither understand the code nor understand the effects your changes make to the code, you don't make the change. The fault squarely lies with the idiot monkeying around in places he shouldn't have.
Or maybe it lies with the idiots that gave someone who doesn't understand the code or the changes commit access...
Re:You insensitice clod... (Score:5, Informative)
I'm pretty sure the only place the changes were committed was Debian patch repos. The whole thing is pretty much Debian-specific.
I think you're trying to make a larger point, so I'll make a larger semi-rebuttal. If projects only gave commit access to people that understood the whole code base they'd never get anything done. Developers with the power to commit, whether to Debian's repository or upstream, should be aware of which code they understand. They should ask questions when they don't understand something, and they shouldn't commit it until they understand the consequences.
I have commit access for Audacity and there are many parts of the program I don't know very well. That's how I operate. Anyone committing changes to OpenSSL ought to at least be as careful as I am with Audacity. I'm sure the actual OpenSSL project is a lot less permissive about giving access to their own repositories, and they probably review changes more closely.
Debian seems to carry a lot of patches against a lot of programs and doesn't seem to ensure the same level of quality. At the same time, Debian has more resources for bug tracking and user reporting than many projects, and maintains security backports for projects that are unwilling. It's a bit of a mixed bag.
Re: (Score:2)
I think you're trying to make a larger point, so I'll make a larger semi-rebuttal. If projects only gave commit access to people that understood the whole code base they'd never get anything done.
Sorry--I should have worded that better. They should only give access to people who either understand the whole codebase or know their limitations and won't mess with things they don't understand.
I have commit access for Audacity
Thank you for helping with a great program. I use it weekly to convert audio files from my boss for use in Asterisk. (And also making the occasional ringtone for my phone...) ;)
1.0.0 (Score:5, Funny)
Meh. I never run version 1.0 of anything.
Re: (Score:3, Funny)
On the up side, it only takes one mouse click and a pop up that says "Are you sure you want to get burnt?" to do so.
Geee! (Score:4, Informative)
Just in time for commonplace MiTM spoofing.
That little lock on your browser window indicating you are communicating securely with your bank or e-mail account may not always mean what you think its means.
Normally when a user visits a secure website, such as Bank of America, Gmail, PayPal or eBay, the browser examines the website's certificate to verify its authenticity.
At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications -- without breaking the encryption -- by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.
The attack is a classic man-in-the-middle attack, where Alice thinks she is talking directly to Bob, but instead Mallory found a way to get in the middle and pass the messages back and forth without Alice or Bob knowing she was there.
The existence of a marketed product indicates the vulnerability is likely being exploited by more than just information-hungry governments, according to leading encryption expert Matt Blaze, a computer science professor at University of Pennsylvania.
"If the company is selling this to law enforcement and the intelligence community, it is not that large a leap to conclude that other, more malicious people have worked out the details of how to exploit this," Blaze said.
http://www.wired.com/threatlevel/2010/03/packet-forensics/ [wired.com]
Banks etc. should publish certs offline Re:Geee! (Score:1)
Easy enough to get around for in-person banks: Have them post their credentials on the walls of their buildings and have a take-home flyer with the same information printed on it.
This won't work for Internet banking and it will cause issues if the bank itself ever changes keys, but barring that it should work. Of course, this assume people who care enough to check.
On a more practical note, web browsers that keep local copies of credentials or at least credential-digests then alert when one changes will pr
Re: (Score:2)
The feds don`t need to do mitm between you and your bank. If they want to go to the trouble of checking your banking activity, they probably have enough evidence to get a search warrant from a judge. It`s your common communications like phone and e-mail that the police want to be able to snoop on without the hassle of a court order. The feds get a copy of major money movements from the domestic banks anyways, and they can figure out how much you have from the interest statements transmitted to the tax coll
Re: (Score:2)
If they want to go to the trouble of checking your banking activity, they probably have enough evidence to get a search warrant from a judge.
This is the important bit, and we don't want it to change. if SSL wiretapping is practicable for the cops, there is now a possibility that it could change.
Which would suck.
Re: (Score:3, Interesting)
The issue is the one of encryption vs. authentication vs. both at the same time, and the fact that SSL/TLS was designed to provide both at the same time only, without any sane way to provide just one of those things at a time, as opposed to, e.g., PGP.
I'm no cryptographer, just a part-time server administrator (and other things too, but this is irrelevant), but my experience, together with plain, old common sense tells me that things would be much easier for both administrators and security guys (is there a
Re:Geee! (Score:5, Informative)
I'm sorry to say it, but if you want privacy, this is wrong. You can have authentication without encryption (digital signatures) but encryption without authentication = Man in the Middle. PGP and SSH don't get around this in any way, shape, or form--they just seed trust differently, with PGP using the web-of-trust model and SSH a repeatability model. Neither of those work very well for the classic "online banking" use case, however--average users are not going to seed their trust webs, and expect to be able to bank from computers at cafes, work, and friends' houses--none of which would have connected previously, making the SSH model unworkable.
That's not to say there's nothing here--extensions to the SSL model like EV certs, DNSSEC, and phishing databases have all made these attacks harder. Perhaps browsers will implement web-of-trust or trust-history type extensions to make it harder yet. And it may well be the case that you simply cannot safely bank at computers you don't own, though with pre-shared keys and time-generated PINs both embedded into mailed fobs, the possibilities open up enormously as long as the execution is correct.
But at the end of the day there's no true privacy without authentication built-in and for the core e-commerce use case, SSL is probably the best model.
Re: (Score:2)
expect to be able to bank from computers at cafes, work, and friends' houses
From a security point-of-view this expectation is frightening. Using their own trusted computer on an untrusted network, sure—that's what TLS was designed for. Using an untrusted client computer, however, is just asking for trouble in the form of keyloggers, malware, insecure settings (are you sure they didn't enter an exception for that invalid certificate?), etc.
As far as that goes, the prevalence of malware in general should make anyone think twice about online banking, even from their own PC. Reme
Re: (Score:2)
security token keyfobs a option?
Re: (Score:2)
security token keyfobs a option?
These can help protect against keyloggers and the like; once you've logged out of your account you should be fairly safe (unless some other attack altered your login credentials). However, if you can't trust the local PC then you're still subject to the other attacks I mentioned: uncertain security against phishing, redirects, etc., and local malware taking advantage of your authenticated connection while you're logged in.
If the keyfob is required for each transaction, and not just the initial login, then y
Re: (Score:2)
The problem is very simple -- browsers come with a list of signing certificates that the browser trusts implicitly. When you visit a website, you're trusting the certificate signing process between any one of those issuers represented in the browser's database and the website you're on. You of course have no way of knowing how those certificates were issued to the domains in question, or if they're reliable or trustworthy.
Importantly, most sites don't use client certificates either, which would help preve
Re: (Score:1)
Re: (Score:2)
Good luck with that. I use Open Source software almost exclusively, and consider it more secure, but don't delude yourself: you can never be completely certain that any software is free of exploitable bugs. For that matter even hardware authentication can be subverted, but the idea is to minimize the surface-area exposed to attack.
A general-purpose PC—whatever OS/apps it's running—has a much larger surface-area than a locked-down, non-updatable, special-purpose device intended exclusively for pr
Re: (Score:2)
Re: (Score:2)
Hence my allusion to fobs late in the post, which of course many banks are adopting. But that still leaves no good alternative to SSL for ecommerce.
Re: (Score:2)
If there is a good alternative for banks, there is a good alternative for ecommerce -- essentially, clearing transactions through the bank through which payment (whether from a deposit account or credit line) is made, using the "good for banking" system.
Re: (Score:3, Interesting)
You mean like DNSSEC?
You can ensure that you are really talking to your bank. If they wanted to (and if the browser was okay with it) they could then publish their public key into their signed DNS, and not only would you know they were them, but that their self signed key was okay. Of course, it takes those poor little certificate authorties out of the picture in many cases, which is why they (verisign does both root DNS servers, and certificates) seem to have been so darn slow to implement it. You could li
Re: (Score:2)
things would be much easier for both administrators and security guys (is there a proper name for them?) if the concepts of data encryption on the wire and authentication of the other party were separated both in protocol and implementation
They're not separable. How can you have any assurance that your communications are secret if you don't know who you're talking to?
Authentication can exist just fine without encryption, but if you want privacy you must have both authentication and encryption.
Re: (Score:2)
Authentication can exist just fine without encryption, but if you want privacy you must have both authentication and encryption.
Encryption without authentication isn't worthless, however: it won't protect you from a targeted attack, but it will help against those throwing their nets far and wide in the hope of seeing something interesting. If all http sessions were encrypted and https differed only by having authentication too, it would make blackhats' lives significantly harder without any obvious downside. In particular it would help also those seriously concerned about privacy by making encrypted communication less conspicuous.
O
Re: (Score:2)
I actually agree with the opportunistic encryption approach. I've posted numerous times on /. about how browsers should silently accept and use self-signed certs, and just not show the lock icon. It's important, though, to understand that opportunistic encryption of that sort is effective only against passive eavesdroppers. Anyone able to mount a MITM attack can defeat it, and the attack doesn't need to be targeted. Indeed attackers with sufficient access and capability can still "throw their nets far a
Re:Geee! (Score:4, Insightful)
To use the Packet Forensics box, a law enforcement or intelligence agency would have to install it inside an ISP, and persuade one of the Certificate Authorities — using money, blackmail or legal process — to issue a fake certificate for the targeted website. Then they could capture your username and password, and be able to see whatever transactions you make online.
Granted, TFA states that a hacker could potentially circumvent the more difficult parts by using social engineering—registering a certificate that looks like it matches a particular web site and hoping surfers will manually accept it. But that's again a problem with the certificate authority and/or user, not SSL itself.
All the article really boils down to is that SSL is useless if the client and server can't trust the certificate authority. Which should be freaking obvious.
Re: (Score:2)
if the time comes that technology works even in the face of human stupidity, humanity have managed to make themselves obsolete.
Re: (Score:2)
> the article really boils down to is that SSL is useless if the client and server
> can't trust the certificate authority. Which should be freaking obvious.
Yet we all do!
Re: (Score:3, Funny)
Like OMFG! Mallory you are such a bitch!
- Alice
Re: (Score:3, Interesting)
To use the Packet Forensics box, a law enforcement or intelligence agency would have to install it inside an ISP, and persuade one of the Certificate Authorities — using money, blackmail or legal process — to issue a fake certificate for the targeted website. Then they could capture your username and password, and be able to see whatever transactions you make online.
This is kind of an important paragraph too. Sure, it's possible to make an appliance that does that, but it is not as simple as the FBI (or any other three-letter organization) buying the boxes. There's a serious legal/technical issue that needs to be overcome as well. Sure, warrantless wiretapping might make some of this possible, but to legally force a Certificate Authority to issue a fake certificate? No Certificate Authority worth anything would undermine their integrity in this fashion, and any law tha
Re: (Score:1)
No Certificate Authority worth anything would undermine their integrity in this fashion
Thanks to how browsers handle SSL certificates, they don't need to get the signing key from a reputable CA, they just need to get one from any CA approved by your browser.
any law that would force them to do so in certain circumstances is effectively giving the government the right to commit forgery in the name of justice
Thanks to some of the provisions in the USA PATRIOT Act, the FBI can send out a National Security Letter [wikipedia.org] and force a CA to turn over their private key. It's unlikely that the CA would publicly disclose that their key had been compromised, as that would be bad for business.
Re: (Score:1)
I agree that this most likely will not happen in the US for the same reasons you stated. However, I do not see this out of the realm of possibility of a more oppressive government like China or N. Korea.
Re: (Score:1)
Who here has "CNNIC ROOT" left over from the default install in their windows(or firefox) cert list? I bet they would be more likely to give up a signed CA cert then VeriSign would.
Re: (Score:2)
Mind you the world is larger than the USA, and if you think there are legal impediments to this happening in the US, there are certainly many parts of the world where the local government would not have any problem (moral or legal) in using such technology.
An attacker doesn't need a cert from the most trusted CA, the least trusted in any of dozens of countries round the world who operate CAs will do.
A CA who was caught doing this would probably be removed by all the browsers, but as yet there's no real mech
Re: (Score:2)
Bank?? Website??
What is this? The dark ages?
Get yourself some FinTS [wikipedia.org] client! (And a bank that offers it. Every bank that doesn’t, is a fraud anyway.)
Re: (Score:2)
do they come as a pocket sized device with a UMTS Radio?
Re: (Score:2)
> http://www.wired.com/threatlevel/2010/03/packet-forensics/ [wired.com]
> The basic point is that in the status quo there is no double check and no
> accountability," Schoen said. "So if Certificate Authorities are doing things
> that they shouldn't, no one would know, no one would observe it. We think at
> the very least there needs to be a double check."
And the tragic thing is, we pay A LOT of money for this nonsense. As far as I am concerned, the entire CA industry was from the get-go one of the biggest
Obligatory meme (Score:2, Funny)
Ovaltine (Score:5, Funny)
Why do they call it Ovaltine? The mug is round. The jar is round. They should call it Roundtine.
Re: (Score:2)
From da wikipage: [wikipedia.org]
Yes, I'm sure you were joking. Haha funny, joke go whoosh.
But it's still a good question with, apparently, a sensible but non-obvious answer.
Re: (Score:2)
Why do they call it Ovaltine? The mug is round. The jar is round. They should call it Roundtine.
You really need a mentor.
Re: (Score:2)
Re: (Score:3, Funny)
That's gold, Jerry. GOLD!
Release announcement and changelog (Score:5, Informative)
http://marc.info/?l=openssl-announce&m=126987886907671&w=2 [marc.info]
http://www.openssl.org/source/exp/CHANGES [openssl.org]
-molo
Waaahoo! (Score:5, Funny)
Fantastic! It's finally ready for production use! I can't until websites start using openssl! And I'll even be able to use a secure shell! Awesome!!
Re: (Score:2)
Woops, there is a bug: It accidentially the whole server!
And in the better-late-than-never department (Score:5, Funny)
From the Changelog:
Re: (Score:3, Informative)
From the Changelog:
Just in time for Haiku [haiku-os.org]. Alternative open source OS's need some love too.
1.0 they finally got it right! (Score:4, Interesting)
Now that the first version is finally in relaase, how long before the first set of changes hits? Everybody knows 1.0 of anything is full of bugs.
And on a more serious note, did anyone ever publish a specification of what a 1.0 release should have in it? Or is this somewhere between "declare victory" and "declare exhaustion"?
Re: (Score:2)
My first thought was that they just ran out of digits in the 0.9 space! :p
(but seriously... great product, I make use of it myself)
Re: (Score:2)
Everybody knows 1.0 of anything is full of bugs.
This is actually changing somewhat, at least when it comes to open source. Go through the repository for any major Linux distro and note how many pre-1.0 packages there are. They may be "pre-release," but that doesn't mean that the quality is terrible.
Remember that an increment in the major version indicates a significant "milestone" of one type or another. Traditionally, the milestone has been the addition of a major set of features. But some open-source packages are using it to mean "release quality."
micro magnum (Score:1, Troll)
In some of these open source projects, version 1.0 is like the first time the odometer in your car rolls over. Or like a couple who finally decide to get married after 15 years of living in sin. I wonder if this big decision involved a trip to Vegas.
Version 1.0 isn't that different from getting marriage. Some enter into it on the basis of hope and enthusiasm with neither experience nor skill, while others circle each other like planets in a decaying orbit.
A long run in the zero point nineties is like the
Re: (Score:1)
Re: (Score:2)
ClosedSource 1.0 = OpenSource 0.1
Documentation (Score:5, Insightful)
openssl(1): [STILL INCOMPLETE]
ssl(3): [STILL INCOMPLETE]
crypto(3): [STILL INCOMPLETE]
HOWTO: [STILL INCOMPLETE]
I would trade in the last 12 months worth of OpenSSL development for some decent documentation. [STILL INCOMPLETE] is a half truth as well; the complete bits suck in novel ways.
Re: (Score:3, Interesting)
This is precisely why I'm using GnuTLS [gnu.org] for a project I'm working on right now. The documentation is fairly complete, with lots of examples, and (probably) every function described. I'm not totally sure about a comparison between GnuTLS vs. OpenSSL in terms of speed or functionality, but as long as the code works well, good documentation can make the difference between using something and not using something.
Re: (Score:2)
Interesting.... (Score:3, Interesting)
Looking over the changelog, it appears Google sponsored alot of the changes.
Guess they wanted to make sure openSSL is a good bit more secure, being that it's a hot button issue and all.
I have great respect for the OpenSSL project... (Score:1, Offtopic)
...but when it comes to version numbers I've grown fond of Ubuntu's approach, with month and year as the version. It makes it very simple to tell if you have a fresh or stale copy of something.
But then again, OpenSSL is a library. Version numbering schemes hardly matter for something like that.
Re: (Score:2)
You could say
Re: (Score:2)
You mean the WINDOWS approach. You know that MS started that “trend”, and that we all hated it, back then?
We still do, for the same reasons.
Also, software doesn’t go stale, so your “argument” is false. If there is nothing to change, because it is fine as it is, and nobody finds bugs despite searching for them, would you stop using a program, just because it’s older??
The reason MS introduced date version numbers, was to HIDE that actually not much changed, and that a updat
Re: (Score:2)
You mean the WINDOWS approach. You know that MS started that “trend”, and that we all hated it, back then?
We still do, for the same reasons.
Actually, Adobe did it with Illustrator way back in 88.
Also, software doesn’t go stale, so your “argument” is false. If there is nothing to change, because it is fine as it is, and nobody finds bugs despite searching for them, would you stop using a program, just because it’s older??
Lots of software goes stale. Libraries cease to work with newer file formats and/or protocols. Programs don't understand newer formats or keep supporting features deprecated ages ago.
Granted, some software can stay the same for decades, but there is a lot that does need updating to keep with the times.
I stand by my argument that having a release with a "date stamp" makes it easier to keep track of these things. It's by no means the only approach, but it
Re: (Score:2)
There is no mathematical difference between a date stamp and a version stamp if they both increment by arbitrary amounts over releases and programmers can't move backward in time.
I don't understand why anyone would discuss such a difference at all.
See the versioning scheme for TeX [wikipedia.org] for another option.
Re: (Score:2)
There is no mathematical difference between a date stamp and a version stamp if they both increment by arbitrary amounts over releases and programmers can't move backward in time.
Good point. :)
I'd heard of the TeX approach before. I like it, but personally I don't have that much fate in the architectural direction most projects to see it as a viable option for universal adoption. ;)
Re: (Score:2)
er, wait. as a kde user, i'm still on kde3, and i could have many complaints about kde4. but...
1. kicker is actually very nice. and i'm saying that as a quite conservative user :)
one *annoying* thing in kde3 version (as per suse) - it opens when mouse is moved in the lower left corner. i hope that thing is at least configurable in kde4, though.
2. single click is actually good... if implemented correctly (which ms never did, which is one of the main reasons it pretty much died off).
and the select/unselect me
Perl dependency (Score:2, Interesting)
Why the flip does it need to depend on perl5? I'll never get ssh running on 386BSD this way.
Re: (Score:2, Funny)
(sorry, obligatory)
haven't you heard? After looking at thousands of perl scripts, it became clear that it's the best way of making something unreadable, so openssl "encrypts" via making obfuscated perl (redundant, I know - as if there's any other kind!). decrypting just needs a key, a perl interpreter, and blood. Of goats. Lots of them.
-- just another brick in the larry wall
Re: (Score:2)
Why the flip does it need to depend on perl5? I'll never get ssh running on 386BSD this way.
It has a circular dependence with Net::SSLeay
Please please keep a stable ABI (Score:2)
OpenSSL has until now had the least stable ABI of all commonly used Unix libraries. Having to upgrade half the system for a change from 0.98f to 0.98g is rather sad. Especially when bug fixes come with ABI changes.
Re: (Score:2)
All their competitors manage it, and there's no bug reports in the Fedora bugzilla about software getting dog slow after switching to Mozilla's TLS-library.
Re: (Score:2)
Yes, but pre-1.0 versions of, well, pretty much anything, do not have stable A[PB]Is. That's one of the things about being pre-1.0; everything is still subject to change.
Now, all future 1.x(.y) releases should be A[PB]I backwards compatible with 1.0.0. If they're not, yes, that would be bad release management. But until they do that, I don't think it's entirely fair to complain about it.
Re: (Score:2)
Yes, but pre-1.0 versions of, well, pretty much anything, do not have stable A[PB]Is.
This would be a valid response for a project which hasn't been in development for over a decade.
Can't wait for the IPad App! (Score:1, Offtopic)
Iphone OS 45.6 ?
Re: (Score:2)
Not bloody likely. OpenSSL and OpenSSH are a wee bit bigger than ubuntu, imo.
11 Years for version 1.0? (Score:1, Flamebait)
Go read Peter Gutmann's X.509 Style Guide if you want to cry. If that doesn't work, try implementing an ASN.1 library from scratch.
I'll take SSH and SPKI any day over the X.509/TLS mess.
Next you're telling me... (Score:2, Funny)
... Duke Nukem Forever has ALSO been released.
Re: (Score:3, Funny)
> ... Duke Nukem Forever has ALSO been released.
It has. But only for HURD right now....
Re: (Score:1)
Damn! I'm running Plan9 here!
NSS (Score:2)
Thing is, Red Hat and friends stopped waiting and already moved to NSS over three years ago. http://en.wikipedia.org/wiki/Network_Security_Services [wikipedia.org]
Re: (Score:1)
I echo my sibling's comment in that I have no problem at all with the website's style - I'd far rather have a simplistic straightforward HTML-driven site than some stupid Javascript-redirect-driven graphic-design student project. This is really important for security-related software distribution sites where it's necessary to be absolutely sure where your downloads are coming from.
The site does however have some problems with organisati