> I think responsibility should fall on companies who used the library without checking it first
Agreed. The OpenSSL license (as do many others), has this very clear (if somewhat hard-to-read) disclaimer in it:
"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."
This is a standard disclaimer in software. It's just there so you can't sue. It doesn't mean OpenSSL was not intended to be a security library for everyone to use, because it obviously was.
I don't like the 'amateur defense' of open source. No, people are not legally liable for code; no, no open-source dev has any obligation to write good code; but OpenSSL is still garbage. As long as you're writing code and using other peoples' code, you might as well care about craftsmanship. If you don't care about craftsmanship, maybe this is the wrong approach to a critical security library.
Couldn't agree more. The only real difference between an engineer and a hobbyist is that one gets paid (sometimes hobbyists get paid too (gittip, etc)). Both need to realize that engineering ethics of what they're involved in. I might need to turn in my hacker badge if I was ever issued one, but I don't support the completely anarchist view point of "screw everyone, it doesn't matter because it's legal" because there is a greater ethical obligation to serve the greater good. It gets real real fast when a pseudo-democracy buys a 0day to a popular open source library to target dissenters and have them shut up.
the problem is that most or almost every professional programmer goes by the slogan "You shouldn't implement cryptography by yourself, but instead rely on the existing well tested libraries". This is hinders competition in the crypto space. You definitely cannot say that the programmers of openSSL are not professionals, because you know that the majority was relying on their library so it is definitely the best library out there. There is just no better alternative. if you want to have alternatives then you have to encourage amateur crypto programmers to implement competing products. But the whole programming community is doing the opposite by bashing people who start implementing their own crypto. For example If I remember the debate about Telegram where a highly talented team starts their own library the response from programmers is that they shouldn't do this and instead use crappy old libraries which do not even fulfill their requirements.
I don't think the advice not to implement your own crypto stuff ever meant that no one should do it under any circumstances. It means that application programmers should not do it as part of their application. And that, I think, is good advice.
I certainly wouldn't want to see corporate devs at my bank implement some custom "secure" http communications protocol.
What we need is two or three well funded TLS/SSL implementations competing with each other, kind of like we have a handful of competing web browser implementations or C++ compiler implementations or operating systems, all done by experts in their field.
> For example If I remember the debate about Telegram where a highly talented team starts their own library the response from programmers is that they shouldn't do this and instead use crappy old libraries which do not even fulfill their requirements.
The problem with Telegram wasn't about code, it was about algorithms and design. They designed their own crypto, which is a really bad thing. If they had written their own implementations of well-known, tested and proven crypto primitives/algorithms, everything would have been fine (well, mostly; you can still implement a good algorithm badly, but that's not what happened).
What? Come on. Get a grip on reality. The code is some of the most efficient and widely used. I think it's also the only code that implements the entire spec.
It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one.
It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one.
It's nothing like that at all. A piece of code's popularity is no evidence of its quality. Otherwise we'd never have advanced beyond BASIC.
Implementing an entire spec is nothing to be proud of. Specs are often over-engineered. This is almost certainly the case for TLS. It's 103 pages long: http://tools.ietf.org/html/rfc5246
We should be questioning the foundations we've been relying on until now when a single vulnerability was able to compromise most of the internet, possibly since 2011.
> The code is some of the most efficient and widely used.
Efficient, yes. Throughput in general is not a problem.
Widely used, well... yes to that too. Although in this regard I would attributed a good chunk of it to inertia. When (common) use of cryptography started to take off around the time of the browser wars, there weren't too many options around. Web servers needed a way to serve protected content, and there was OpenSSL.
Not just available, but already supported by language bindings and relatively easy to set up thanks to mod_ssl.
First mover advantage + network effects + the fact that getting crypto right is really hard. If you wanted to unseat OpenSSL, you would need to overcome the fact that despite all the bad rap and the butt-ugly, and the leaky API, it was still getting the most exposure and field testing. Unlike some newcomer library, OpenSSL has the advantage that it is firmly embedded in the software ecosystem, and it has benefited from more than a decade of bugfixes. (I still remember when the timing attack for extracting RSA keys was discovered. The bug was pretty much everywhere, and not just in OpenSSL.)
The widespread use of the library boils down to a simple and womewhat depressing fact: OpenSSL is used everywhere because OpenSSL is used everywhere.
Replacing it with something better will be a long uphill battle. Any newcomer would need an aggressive test suite which covered EVERY known implementation bug. And a sane API. And a project with the political savvy to succesfully lobby for its use through all avenues.
If the skyscraper collapses on me I feel entitled to say that it was garbage even if I'm not capable of building one.
But I am a half decent C programmer and I saw the code that included the heartbleed bug. This bug wasn't caused by a subtle issue. It wasn't even a logical error that a competent person could easily make in a confused moment. This was pure negligence, and negligence is rarely isolated in one part of a codebase.
PHP5 is widely used. The security history of that is less than awesome.
I think OpenSSL is better than I could do or most people could do, but again, it's still at the mercy of C AND a wide range of TLS and other features that seem to multiply like rabbits.
I think we really need a much, much simpler TLS standard going forward.
Agreed. The OpenSSL license (as do many others), has this very clear (if somewhat hard-to-read) disclaimer in it:
"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."