openssl.org · Domains · Slashdot Mirror

Good luck contacting some of those contributors... by Anonymous Coward · 2017-03-27 03:55 · Score: 0 · on After 20 Years, OpenSSL Will Change To Apache License 2.0, Seeks Past Contributors (openssl.org)

Re:Not everyone is happy... by mysidia · 2017-03-26 12:58 · Score: 2 · on After 20 Years, OpenSSL Will Change To Apache License 2.0, Seeks Past Contributors (openssl.org)

They need to make such an assumption if they want to make progress as some people may no longer be reachable

Regardless of what is convenient for the project, the DEFAULT Under copyright is ALL RIGHTS RESERVED.
The licensing for the contributions were not implicit.... OpenSSL contributions were made under a specific license
https://www.openssl.org/source...

The license they put it under has a SPECIFIC statement Barring license changes:
* The licence and distribution terms for any publically available version or

* derivative of this code cannot be changed. i.e. this code cannot simply be

* copied and put under another distribution licence

* [including the GNU Public Licence.]

*/

Re:What was the old license model? by mysidia · 2017-03-26 12:44 · Score: 4, Informative · on After 20 Years, OpenSSL Will Change To Apache License 2.0, Seeks Past Contributors (openssl.org)

Basically two Extended 3-Part BSD licenses WITH Advertising Clause, therefore the Purists would
claim they are GPL-Incompatible, and GPL Software should not link with OpenSSL --- Although I do not
agree with that assessment. No issues linking to OpenSSL so long as you obey the terms of the OpenSSL license
in the binary distribution of OpenSSL, and the GPL in the terms of the distribution of the software linking to openssl.

https://www.openssl.org/source...

Feed /dev/zero into a CBC cipher with OpenSSL by tepples · 2016-06-29 02:52 · Score: 3, Interesting · on Study: 78% of Resold Drives Still Contain Readable Personal or Business Data (consumerist.com)

Some SSDs use lossless data compression (analogous to gzip) to pack more sectors into fewer physical pages so that they don't have to spend quite as much time erasing pages. To avoid this possibility, you might want to use a cipher to generate noise that the drive's firmware cannot compress.

TRIM the entire drive.
Feed /dev/zero into a CBC cipher with openssl enc .
Perform a "Secure Erase".

"Export Jobs, Not Crypto" Policy by Scorpinox · 2016-02-11 05:30 · Score: 3, Insightful · on US Encryption Ban Would Only Send the Market Overseas (dailydot.com)

If you want to make software that uses cryptography available worldwide, you're already incentivized to develop it in a foreign country and import it to the US. There's no restriction on using foreign cryptography in the US, but there are legal hurdles you have to jump if you want to export cryptography from the US.

OpenSSL themselves mentions exporting as an alternative to costly legal counsel:
"The only other safe course of action would be to pay non-U.S. citizens to develop the cryptographic software overseas and import it into the U.S., as imports are not restricted. Foreigners who benefit financially from this situation refer to the U.S. “export jobs, not crypto” policy." https://www.openssl.org/docs/f... (page 145)

Re:Not Sure What the HTTPS Hooplah is all about by mysidia · 2016-01-29 15:14 · Score: 1 · on Google Will Soon Let You Know By Default When Websites Are Unencrypted (softpedia.com)

and provides for VERIFICATION

In security, there are exactly Three kinds of verification regarding a principal: Authentication - Confirms that a party is whom they claim to be
Authorization - Confirms that a party is permitted to proceed with the requested action
Auditability/Non-Repudiation - Confirms that the party commits to the requested action and cannot later pretend they didn't do it, or did it at a different time / under different conditions

No authentication involved.

INCORRECT. With the HTTPS protocol, a Server Certificate is used to Authenticate the server to the client.

In fact, the type of certificate required is one that has the serverAuth Key Usage (Short for "TLS Server Authentication")

You can see that over here: https://www.openssl.org/docs/m...

This extensions consists of a list of usages indicating purposes for which the certificate public key can be used for:

serverAuth SSL/TLS Web Server Authentication.

yes it was. Here's the changelog by raymorris · 2015-12-05 02:40 · Score: 1 · on No More Security Fixes For Older OpenSSL Branches (csoonline.com)

> OpenSSL wasn't even around in 1998.

Here's the OpenSSL changelog, including changes in 1998 releases such as 0.9.8g. The 0.9.x.y branch lasted a long time.
https://www.openssl.org/news/c...

As you said , 1.0.1 wasn't released until 2012.

Mysterious?!! (much ado about nothing) by Demonoid-Penguin · 2015-07-07 23:05 · Score: 1 · on 'Severe Bug' To Be Patched In OpenSSL

When processing an ECParameters structure OpenSSL enters an infinite loop if the curve specified is over a specially malformed binary polynomial field. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. This includes TLS clients and TLS servers with client authentication enabled.
original advisory Hidden in plain sight. (sigh)

Isn't The Register a news satire site? [if not it needs reclassifying]

Re:OpenSSL has been replaced... by Anonymous Coward · 2015-06-12 03:49 · Score: 0 · on New OpenSSL Security Advisory Announced

All of them are from this OpenSSL release: http://openssl.org/news/secadv...

Some explanation, and what OpenSSL is doing by rich_salz · 2015-05-20 04:17 · Score: 1 · on 'Logjam' Vulnerability Threatens Encrypted Connections

Emilia from the OpenSSL team just published a good blog post that explains some of the "twists" of logjam, and also what OpenSSL is doing about it. It's here: http://openssl.org/blog/blog/2...

Re:Is there any way to block the use of old cipher by chill · 2015-03-03 09:56 · Score: 3, Interesting · on FREAK Attack Threatens SSL Clients

Yes. http://www.openssl.org/docs/apps/ciphers.html

The question is does OpenSSL accept the weak ciphers as a downgrade bug even when EXPLICITLY DISALLOWD.

I haven't seen answered in any of the linked articles so am digging/testing.

After the last couple of bugs my organization set the explicit cipher/algorithm/has acceptable list. The export ciphers were excluded on purpose from our list.

SSL Labs https://www.ssllabs.com/ has a recommended list buried in their documentation somewhere.

Re:Not realistic indeed. by gweihir · 2014-07-17 04:20 · Score: 1 · on LibreSSL PRNG Vulnerability Patched

The OpenSSL docu says "Be careful when deferring to RAND_poll on some Unix systems because it does not seed the generator." As far as I can see, RAND_poll() is not mentioned in the official OpenSSL interface definition at https://www.openssl.org/docs/c... at all, so it is more of an internal, hidden function, and should not be used by the library user. It is mentioned on http://wiki.openssl.org/index...., but with the clear warning above. Also note that it says "OpenSSL will attempt to seed the random number generator automatically upon instantiation...", which is another warning not to trust the internal initialization.

Now, I would say that this is enough to warn anybody. But in order to prevent people from shooting themselves in the foot, I agree that RAND_poll() should not even be there unless it works reliable or at least tells the user its success or lack thereof in a return code. (In a sense, it is not there. It likely should be hidden better though.) My guess would be that the LibreSSL team wants to remove this broken-by-design function and in a first step mistakenly disabled it, making the problem temporarily worse on some platforms. This also means that a careful developer will use RAND_seed() or RAND_add() and at most use RAND_poll() in addition. To prevent platform dependency, you can pull, say 256 bit from the CPRNG and use that with RAND_seed()/RAND_add() in the child, while the parent continues without using it. As RAND_poll() (if done right) may be quite slow, that is also superior from a performance perspective.

Trusting these transparent mechanisms has historically been a real risk. A careful crypto user will know that. The last time it went haywire was with Android, where if you seeded in addition yourself, this wiped out the secure initialization. This was documented as well, but only in the Android Java pages, not the regular ones. And some 50k Apps fell for it. Seems solid understanding of crypto is still hard to come by. CPRNG seeding is critical and _must_ be done right. That includes reading and understanding all the documentation of the functions you use. The person using RAND_poll() after a fork clearly failed at that, by a) not reading or not understanding the documentation and b) using an internal, hidden function for a critical task. This had non-surprising consequences.

Re:Not realistic indeed. by gweihir · 2014-07-17 04:20 · Score: 1 · on LibreSSL PRNG Vulnerability Patched

The OpenSSL docu says "Be careful when deferring to RAND_poll on some Unix systems because it does not seed the generator." As far as I can see, RAND_poll() is not mentioned in the official OpenSSL interface definition at https://www.openssl.org/docs/c... at all, so it is more of an internal, hidden function, and should not be used by the library user. It is mentioned on http://wiki.openssl.org/index...., but with the clear warning above. Also note that it says "OpenSSL will attempt to seed the random number generator automatically upon instantiation...", which is another warning not to trust the internal initialization.

Now, I would say that this is enough to warn anybody. But in order to prevent people from shooting themselves in the foot, I agree that RAND_poll() should not even be there unless it works reliable or at least tells the user its success or lack thereof in a return code. (In a sense, it is not there. It likely should be hidden better though.) My guess would be that the LibreSSL team wants to remove this broken-by-design function and in a first step mistakenly disabled it, making the problem temporarily worse on some platforms. This also means that a careful developer will use RAND_seed() or RAND_add() and at most use RAND_poll() in addition. To prevent platform dependency, you can pull, say 256 bit from the CPRNG and use that with RAND_seed()/RAND_add() in the child, while the parent continues without using it. As RAND_poll() (if done right) may be quite slow, that is also superior from a performance perspective.

Trusting these transparent mechanisms has historically been a real risk. A careful crypto user will know that. The last time it went haywire was with Android, where if you seeded in addition yourself, this wiped out the secure initialization. This was documented as well, but only in the Android Java pages, not the regular ones. And some 50k Apps fell for it. Seems solid understanding of crypto is still hard to come by. CPRNG seeding is critical and _must_ be done right. That includes reading and understanding all the documentation of the functions you use. The person using RAND_poll() after a fork clearly failed at that, by a) not reading or not understanding the documentation and b) using an internal, hidden function for a critical task. This had non-surprising consequences.

Re:Happy to let someone else test it by greg1104 · 2014-07-11 23:45 · Score: 2 · on First Release of LibreSSL Portable Is Available

Most of FIPS is a certification process oriented on testing. However, there is a checklist of things you need to support, and one of them used to be the easy to backdoor Dual_EC_DRBG.

Now that the requirement for Dual_EC_DRBG has been dropped from NIST's checklist, it would be possible to have LibreSSL meet FIPS requirements without having the troublesome component. Most of FIPS certification is about throwing money at testing vendors, as described by OpenSSL themselves. Doing that would really be incompatible with the crusade LibreSSL is on though, because the result is believed by some to be less secure than using a library that isn't bound to the FIPS process. I don't see those developers ever accepting a process that prioritizes code stability over security.

Re:Donate by WaffleMonster · 2014-07-11 13:54 · Score: 1, Insightful · on First Release of LibreSSL Portable Is Available

First of all, OpenSSL problems are not ''getting fixed''.

http://www.openssl.org/about/r...

Third, the amount of code that has been cleaned up, improved, deleted and just plain scrubbed is simply amazing. You can say whatever you want about OpenBSD cranky devs, they know their stuff and they know their way around C code.

Nothing structural has changed.

Heartbleed didn't arise from confusing seas of preprocessor macros or broken allocators we've been hearing so much about. It was allowed to happen because there were no structures in place mandating early data validation up front.

Re:OpenSSL and what else. by Forever+Wondering · 2014-05-29 09:02 · Score: 1 · on OpenSSL To Undergo Security Audit, Gets Cash For 2 Developers

The OpenBSD folks forked OpenSSL into LibreSSL. In addition to checking security, they are doing general code cleanup, removing unnecessary/dead code. They did a talk recently about what they've accomplished: https://www.youtube.com/watch?...

IMO [as a programmer of 40+ years (30+ with C)], the programming style of the code is horrible. One of the functions that produced heartbleed is called dtls1_process_heartbeat. For starters, it has one of the worst indenting schemes I've seen and seems to violate most style/best practice guides I've read. It isn't surprising that a bug [security or not] would creep in.

Here's the original commit for the code:
http://git.openssl.org/gitweb/...

Here's the commit for the heartbleed fix:
http://git.openssl.org/gitweb/...

Re:OpenSSL and what else. by Forever+Wondering · 2014-05-29 09:02 · Score: 1 · on OpenSSL To Undergo Security Audit, Gets Cash For 2 Developers

The OpenBSD folks forked OpenSSL into LibreSSL. In addition to checking security, they are doing general code cleanup, removing unnecessary/dead code. They did a talk recently about what they've accomplished: https://www.youtube.com/watch?...

IMO [as a programmer of 40+ years (30+ with C)], the programming style of the code is horrible. One of the functions that produced heartbleed is called dtls1_process_heartbeat. For starters, it has one of the worst indenting schemes I've seen and seems to violate most style/best practice guides I've read. It isn't surprising that a bug [security or not] would creep in.

Here's the original commit for the code:
http://git.openssl.org/gitweb/...

Here's the commit for the heartbleed fix:
http://git.openssl.org/gitweb/...

Re:All hail Theo! by Anonymous Coward · 2014-05-18 03:48 · Score: 1 · on 30-Day Status Update On LibreSSL

OpenSSL® is a registered trademark of the OpenSSL Software Foundation, Inc.

source: www.openssl.org/docs/fips/UserGuide-2.0.pdf

Re:Get it FIPS certified by greg1104 · 2014-04-22 03:41 · Score: 1 · on Not Just a Cleanup Any More: LibreSSL Project Announced

That's not quite right either. The open-source releases of OpenSSL certainly do not ship with any implied FIPS certification. OpenSSL does offer FIPS validation for a specific build as part of their commercial support program. They say "Support for the FIPS Object Module, including assistance with building a validated module for a specific platform (if possible) is available with the Premium plan". It is not correct that these versions are exactly the same code as the ones first certified long ago.

There was an interesting post to the openssl annoucement mailing list about Flaws in Dual EC DRBG that sheds some more light on this area. It says: "The OpenSSL FIPS module is commonly used as the basis for rebranded proprietary validations (we call these 'private label' validations)", "FIPS 140-2 validations are expensive and difficult, taking on average a year to complete and we have to wait years between validations", and "Even if we wanted to fix it our options are severely constrained by the fact that the CMVP process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review."

All this implies there absolutely are later versions of OpenSSL with FIPS certification out there. You just can't get one without significant input from the commercial end of the OpenSSL Foundation.

Re:Or.. by xxxJonBoyxxx · 2014-04-22 01:32 · Score: 1 · on Not Just a Cleanup Any More: LibreSSL Project Announced

PolarSSL doesn't have the same licensing model as OpenSSL, so it's not a drop-in replacement. (https://polarssl.org/how-to-get vs. http://www.openssl.org/source/...)

Re:OpenSSL OR... by greg1104 · 2014-04-15 09:26 · Score: 1 · on OpenBSD Team Cleaning Up OpenSSL

It's not "simply" though. The interfaces in OpenSSL and GnuTLS are not swappable APIs. We went over this a few years ago for PostgreSQL, and one of the major issues was having too many OpenSSL-isms in our code to swap easily.

Those of us who dislike bad open source licenses have been trying to kick OpenSSL out of projects for years now, and it hasn't gone anywhere but upward in adoption. I've been amazed at how often I see its advertising clause in the credits of video games I play.

Re:Don't keep vulnerable servers running! by jonwil · 2014-04-13 08:17 · Score: 1 · on Private Keys Stolen Within Hours From Heartbleed OpenSSL Site

https://www.openssl.org/docs/a... suggests that OpenSSL (the official upstream version at least) does in fact support DHE and PFS without EC.

Re:This seems plausable by Smallpond · 2014-04-11 11:04 · Score: 3, Interesting · on NSA Allegedly Exploited Heartbleed

This patch was submitted at 7pm on Dec 31st, 2011, so the only people looking at it were the ones expecting it. I guess they were not disappointed.

http://git.openssl.org/gitweb/...

Re:It's not just the implementation by Anonymous Coward · 2014-04-10 21:26 · Score: 0 · on Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

If this was a conspiracy, intentional coding would be required for exploit. Given that, I find it difficult to accept that an agency intentionally first complicated the spec by including a length field (which *could* be checked, in the name of security, for protocol robustness rather than local memory ops); then hen perverted a particular implementation in a manner that looks exceedingly garden variety. Easier to never have the length field in the first place
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504
"Submitted by: Robin Seggelmann "
https://tools.ietf.org/html/rfc6520
"R. Seggelmann" (main author)
Easier if you're both the one making the spec, and the one implementing it... You're in a position of being trusted ("he is the RFC author, he knows what he's doing best, and it's a public spec recognized by the IETF, he's a big guy"). Plus obviously the more cruft, the easier to hide things...

Re:He's sorry now ... by PhilHibbs · 2014-04-10 21:18 · Score: 1 · on Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

https://www.openssl.org/source...

If you never agreed to that license, you're violating their copyright.

You're only violating their copyright if you distribute it. If I legally acquire a copy of a piece of software, I can use it without agreeing to any other stipulations. Depending on jurisdiction, of course, different legal systems may rule in different ways on that point. And I'm not sure what the jurisdiction that this guy lives in has said about it.

The GPL has a specific clause pointing this out, and it's there because the authors of the GPL believe that they have no authority to prevent you from using their software. I agree with them. It always amuses me when GPL'd software contains a clickthrough insisting that you press an "Agree" button, when the licence specifically says that no such agreement is necessary.

Re:He's sorry now ... by drnb · 2014-04-10 14:22 · Score: 2 · on Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

Lawyers love EULA's and licenses. The OpenSSL license disclaims all liability

* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE.

https://www.openssl.org/source...

If you never agreed to that license, you're violating their copyright.

OK, switching from humor to serious. The above can be challenged in court. And being correct/innocent does not necessarily determine the outcome of a case. As a hostile lawyer once explained: the facts of the matter are irrelevant, my client can afford to go to court, you can not. See "pyrrhic victory".

Re:He's sorry now ... by viperidaenz · 2014-04-10 12:48 · Score: 2, Informative · on Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

Lawyers love EULA's and licenses. The OpenSSL license disclaims all liability

* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.

https://www.openssl.org/source...

If you never agreed to that license, you're violating their copyright.

Re:Yep by Anonymous Coward · 2014-04-10 07:50 · Score: 0 · on Theo De Raadt's Small Rant On OpenSSL

There's not even any documentation. I mean, literally, none.

Lies http://www.openssl.org/docs

Nothing vaguely useful. How do I programmatically load a certificate into the store

You copy them to the same directory as all other trusted certificates. Loaded by http://www.openssl.org/docs/ss...

Cert filename you will use is keyed to hash of cert (e.g. openssl x509 -hash ...)

and then set my requirements (must be in-date, must be validly signed, etc.) and get out a "It's fine" / "Something's not right" response?

If you want custom behavior during chain validation you need to create your own verify callback.
https://www.openssl.org/docs/s...

Otherwise see here to set validation parameters:
https://www.openssl.org/docs/s...

It's just that bad. I was writing a pseudo-DRM for a game / Steam-like distribution platform as a hobbyist project. It was literally horrible to even try to self-sign some certificate and then see if it all panned out later from another computer to guarantee integrity. In the end, I had to "imagine" every possible case and find a way to counter it (i.e. client cert expired, client cert invalid, server cert not signed client cert, server cert has bad chain of trust, client cert not signable for that purpose, etc.) - and almost always there was NOTHING to indicate what the recommended way to do it was.

The above API calls handle trust chain validation. If you also need to query cert parameters (name validation) see https://www.openssl.org/docs/s...

There is no decent OpenSSL documentation at all. Not even a decent overview of the process of checking certificates. It scared me at the time, knowing how important the library is, and it can only lead to bad code.

Having visited several areas of OpenSSL API where there is no documentation I agree it is not complete or the best but hardly terrible or non-existent.

Those places most lacking documentation are almost always very specialized where anyone going there should expect to have to read example/test code. Examples you have provided for lack of documentation appear to be relatively trivial, well traveled and relatively well documented.

It scared me at the time, knowing how important the library is, and it can only lead to bad code.

I think there are dangerous and stupid things in OpenSSL like this business of having to register locking primitives to protect the session cache which I have seen take a number of developers both in commercial and open source projects by surprise.

Having looked at the "heartbleed" patch and surrounding code portions very much seem to be full of questionable practices. But hey its open source .. we can all work to fix the problems if we feel they are worth our time to fix. From my perspective everyone is better off if those of us able to step up and fix what is broken rather than or at least in addition to throwing stones.