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.
An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.
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"?
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.
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:Geee! (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 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. Besides the obvious benefit of being able to encrypt the connection without those silly, cartel-provided certificates (even without indicating anything at all to the user, so they don't get a false sense of having more security in place than there is, default encryption of the most popular protocols would do much to thwart all but the most determined wiretapping and eavesdropping attempts), such a separation into two distinct technologies should make it a lot harder to break both things at the same time, and a lot easier to fix any single one of them that someone managed to break without affecting the other.
Of course I could be wrong, and even if I'm not, there's too much inertia in technology and too much money in the SLL certificate cartels for anything to change in this direction, but at least I still have my right to rant a little bit.
Re:Geee! (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 literally "walk the tree" from the root DNS zone to your address you are looking at, and make sure they are all valid.
Re:Geee! (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 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. Such a law would be the pinnacle of hypocrisy. Don't get me wrong; I don't underestimate the erosion of freedom in the United States, but I'm having a hard time believing that any government would act with such impunity. I was unable to find any example of a law enforcement agency using forged documents to entrap a suspect, probably because such evidence would not hold up in any court that truly represented justice.
Re:Documentation (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.