OpenSSL 1.0.0 Released

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."

Comments

Re:You insensitice clod...

[Anonymous Coward]

insensitice

You insensitive clod! My eyes hurt from reading that misspelling!

Geee!

[Philip K Dickhead]

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/

Re:Geee!

[rmm4pi8]

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.

Release announcement and changelog

[molo]

http://marc.info/?l=openssl-announce&m=126987886907671&w=2

http://www.openssl.org/source/exp/CHANGES

-molo

Re:And in the better-late-than-never department

[CharlyFoxtrot]

From the Changelog:

• BeOS support.

Just in time for Haiku. Alternative open source OS's need some love too.

Re:You insensitice clod...

[Al Dimond]

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.