Domain: openssl.org
Stories and comments across the archive that link to openssl.org.
Comments · 173
-
Good luck contacting some of those contributors...
- #1886 beldmit@example.com
- #1527 bugs@openssl.org
- #401 other@bad.org
-
Good luck contacting some of those contributors...
- #1886 beldmit@example.com
- #1527 bugs@openssl.org
- #401 other@bad.org
-
Good luck contacting some of those contributors...
- #1886 beldmit@example.com
- #1527 bugs@openssl.org
- #401 other@bad.org
-
Re:Not everyone is happy...
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?
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. -
Feed /dev/zero into a CBC cipher with OpenSSL
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
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
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 conditionsNo 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
> 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)
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...
All of them are from this OpenSSL release: http://openssl.org/news/secadv...
-
Some explanation, and what OpenSSL is doing
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
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.
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.
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
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
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.
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.
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!
OpenSSL® is a registered trademark of the OpenSSL Software Foundation, Inc.
-
Re:Get it FIPS certified
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..
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...
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!
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
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.
-
Re:It's not just the implementation
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 ...
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 ...
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 ...
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
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. -
Re:Yep
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. -
Re:Yep
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. -
Re:Yep
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. -
Re:Yep
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. -
Re:Summary.
The heartbleed bug works by the user sending a payload which OpenSSL analyzes and determines to be of a length, like strlen(). Then it calls malloc() to allocate a buffer for that length, and copies that length in. 1 byte payload, malloc(1). Then it looks at the heartbeat handshake, which says, "Oh yeah, my payload is 64KB". Then it allocates a 64KB buffer and does a memcpy() of 64KB from that 1 byte buffer into the 64KB buffer.
Do you see the problem here? The server looks at the actual data and malloc()s something the size of the data. The client says, "The data is this big," and the server copies something the size the client dictates from where it allocated the data. Problem: what if the data is actually smaller?
Also, for good measure: The entire bug occurs between an allocation and a free. There actually isn't a free/realloc bug involved. Here, I'll show you.
This is the vulnerable code. Start on line 3963.
Line 3974 starts the problem. Variable (p) is an array of bytes; the first 2 bytes are an unsigned int. n2s(p, payload) is essentially (payload = (unsigned int)(*p);). The (payload) value is an unsigned int carrying the length of the payload.
Line 3991 is your buffer allocation. And it looks like I'm wrong: it allocates a short buffer, which it writes outside of. This was not mentioned on the analysis I read. So a canary should catch this on free() when actively exploited, but not in non-exploit operation.
Line 3997 is the good part: it copies however many bytes you asked for from the SSL Heartbeat request into the payload buffer. That could be 64kb of shit, and the payload is 1 byte long.
Line 4002 sends the copied bytes back to the client. This is where the exploit succeeds.
Line 4009 is where the free() happens. If your glibc has canaries, it crashes here on exploit; this call works normally if you're not being exploited. It also works normally if your payload is short (although other errors may occur elsewhere).
Even so, it crashes IF AND ONLY IF it's being exploited, and only AFTER exploit returns data, and ONLY on write-bounds-checking allocators that look for a dead canary (which you'll actually know after the first exploit--on a forking process like Apache--and can supply with further exploits, so you can rapidly mine with one crash). If you're not testing it by asking for a bigger payload than you supply, you won't ever get this crash.
This isn't a double-free() issue. It's a bounds check issue.
-
Re:git blame of the bug please
http://git.openssl.org/gitweb/... probably introduced it (judging from git blame), http://git.openssl.org/gitweb/... fixed it.
-
Re:git blame of the bug please
http://git.openssl.org/gitweb/... probably introduced it (judging from git blame), http://git.openssl.org/gitweb/... fixed it.
-
Re:Linux is not an Operating System
GnuPG implements RFC4880. See also the OpenPGP alliance. GnuTLS implements SSL, TLS and DTLS. See also OpenSSL and PolarSSL.
Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.
It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.
-
Re:Time for an entropy server?
I just found a cool solution to the problem: the Raspberry Pi has a hardware random number generator as part of the system-on-a-chip, and Linux supports it. So
/dev/hwrng works on a Raspberry Pi and should be able to provide a lot of random data.I don't think Linux will grab entropy from
/dev/hwrng and use it for /dev/random, but you can install rngd (random number generator daemon) from rng-tools; this will pump entropy from /dev/hwrng into the Linux kernel for /dev/random to use.So, you could do the "entropy server" idea, but co-located with your other servers, with the server costing about $35 and electricity costs of pennies per year.
Or, you could just set up server hardware that has a supported hardware RNG on the chip. "Ivy Bridge" i5 and i7 chips have this. (I only use AMD chips, and this feature isn't enough to make me switch.)
-
Re:Amateurs. OpenSSL is _not_ the problem.
This is not an OpenSSL-flaw. Proper initialization of a CPRNG is critical and the OpenSSL documentation states that. The choice of OpenSSL is however especially bad with a bad initialization, as the OpenSSL CPRNG does not continue to seed the generator with additional entropy during its operation, unlike
/dev/random or /dev/urandom. Google messed up spectacularly in two regards:According to FAQ if
/dev/urandom is there openssl uses it. -
OpenSSL?
OpenSSL has had a good working implementation of ECDSA/ECDH for years: http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography
What exactly does BlackBerry have chained down that we don't have an open solution for?
-
OpenSSL?
OpenSSL has had a good working implementation of ECDSA/ECDH for years: http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography
What exactly does BlackBerry have chained down that we don't have an open solution for?
-
Re:Completely useless...
Don't forget the symmetric may change several times in a course of an TLS session. It is called renegotiation. It was made to make things more secure than a single symmetric key but funnily enough, it got exploited...
https://tools.ietf.org/html/rfc5746
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION
-
Cool!
Now Americanz can sell computerz with openSSL configured to for'nerz like Mark J. Cox, Ralf S. Engelschall, Dr. Stephen Henson, Ben Laurie, and...
-
Re:Being non-proft does not justify being incompet
OpenSSL is certified (entry 1747 on that page, "OpenSSL FIPS Object Module"), and they ship a FIPS-specific tool.
-
Re:NEWS Flash!!
Linux doesn't work completely on brand new hardware!!
It works great on our hardware. We get Linux working on it before we release it. We push the support into the kernel and GCC and binutils and all the other stuff before it becomes an issue.
Apple are hardly going to be focusing on cleaning up Linux's issues.
-
69.55.55.93 caught trying to exploit recent SSL vu
Vuln references:
- http://www.openssl.org/news/secadv_20120419.txt
- http://it.slashdot.org/story/12/04/19/1351203/major-openssl-security-issue-found-and-fixedFrom the tor mailing list url below, they don't sound imo too concerned over it, but imo they really should be and so
should you if you use Tor! Monitor your logs in Tor and be aware of any bad entries highlighted in Vidalia in yellow related
to this vuln!This message was posted to the most recent Tor Blog post comments area, awaiting approval. Please share this information with others and add this IP's fingerprint into your torrc file's block list. They could change their fingerprint at any time, so check the tor router list ( at http://torstatus.blutmagie.de/ ) for this IP or an IP within the range listed below for any new fingerprints and add them to your blocked section of your torrc file.
OFF TOPIC :
Please update the TBB with the newest version of OpenSSL.
Today I received my first ever SSL cert error within Vidalia, using the latest TBB version for my platform of choice.
I have never witnessed this error in the past. The error in the logs showcased several lines of errors, around 4, I believe, and it was directly related to the OpenSSL vuln, in my guess.
I regret not saving the error logs, but at the time I shrugged it off.
I do recall the IP associated with the error:
Router Name: whywouldiwanna
IP: 69.55.55.93
FP: $9e1dd7c6fa7f72b9473daf3f0780bbc7c1ce670fDetail:
http://torstatus.blutmagie.de/router_detail.php?FP=9e1dd7c6fa7f72b9473daf3f0780bbc7c1ce670f
I'm familiar with the related discussion here:
https://lists.torproject.org/pipermail/tor-talk/2012-April/024031.html
but I believe it to be incorrect.
I strongly believe an updated release of all TBB versions' OpenSSL should be updated AT ONCE.
Let's not speculate, put this update into motion!
OrgTechEmail: abuse@realitychecknetwork.com
-
Re:Anyone want to translate this into dummy speak?
Is this a remote exploit?
For some applications, it will be, please see the advisory
Any application which uses BIO or FILE based functions to read untrusted DER format data is vulnerable. Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.
Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc) are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected.
Applications only using the PEM routines are not affected. S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or SMIME_read_CMS *are* affected. -
Re:Anyone want to translate this into dummy speak?
Is this a remote exploit?
Yes.
Does this mean my client can be overrun if a server throws me a bad packet or two?
Yes.
Based on the advisory, I can't fully agree with either of these statements.
The advisory states:Any application which uses BIO or FILE based functions to read untrusted DER
format data is vulnerable.DER is a format for the certificate key. For the most part it's relatively rare to handle untrusted certificate keys. I suppose it's possible if you're doing some form of authenticating the client end as well as the server end via SSL.
Please correct me if I'm wrong, but I don't see much evidence this vulnerability is anything worth worrying about for the vast majority of people.
Advistory at: http://www.openssl.org/news/secadv_20120419.txt
-
Re:Anyone want to translate this into dummy speak?
Are you sure about that?
The advisory says that SSL/TLS code is not affected, and only software that parses ASN.1/DER structures from BIO or FILE streams could be impacted. Parsing ASN.1 from memory is also not affected. That would appear to restrict the vulnerable software quite a bit.
Whether you have a remote vulnerability or not would seem to depend very highly on what software you're running.