Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL after Heartbleed

lwn.net

Post reply on HN
Print view View original

31–40 of 80 posts

Re: OpenSSL after Heartbleed

#31

Post by dom0 »

mitchtbaum wrote: post #10
TwoBit wrote: post #4

Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstr…

Gosh, to fix such a problem we'd almost need some kind of machine that can run a different program than its current one. Perhaps with evidence of that as a possibility, we could use a good crypto library instead, eg. https://github.com/jedisct1/libsodium

libsodium is not an OpenSSL replacement and doesn't want to be. It's a cryptographic primitive library and generally doesn't implement cryptographic protocols (eg. TLS, X.509, CMS, CRLs, OCSP, ...).

Re: OpenSSL after Heartbleed

#32

Post by gbrown_ »

yalooze wrote: post #27
iUsedToCode wrote: post #26

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/

> it was created as a direct response to Heartbleed

The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes.

https://youtu.be/GnBbhXBDmwU?t=308

Re: OpenSSL after Heartbleed

#33

Post by vtlynch »

akira2501 wrote: post #18
zAy0LfpBZLC8mAC wrote: post #13

> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream. ... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too…

That was something else that irked me in the article, where they decry the small $2,000 a year they receive in donations; but they don't address how much their commercial support contracts[1] bring in. OpenSSL seems to be both an open source project and a cottage industry all wrapped in one. [1] https://www.openssl.org/support/contracts.html

The first date that Archive.org has that page is August 2015, after heartbleed. Do you know for sure that they offered this service before heartbleed?

Re: OpenSSL after Heartbleed

#34

Post by lmm »

iUsedToCode wrote: post #26

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

It's a coordination problem. If one company started trying to do it, they'd end up having to fund development while everyone else free-rode. And fundamentally there simply isn't that much money lost to security issues yet.

Re: OpenSSL after Heartbleed

#35

Post by cm3 »

The original NaCl had assembly implementations, I believe generated with a Perl script (not unlike OpenSSL's asm generator), and looking around libsodium I cannot see assembly implementations of the loops. Does anyone know why that is? I believe the Linux kernel implementation of ChaCha20 carries asm versions.

Re: OpenSSL after Heartbleed

#36

Post by zeveb »

> The code was hard to maintain and hard to contribute to, especially for developers in the US due to crypto export issues.

That's not really true: per https://www.bis.doc.gov/index.php/policy-guidance/encryption..., publicly available software (which includes free software) just requires a notification under exception TSU. All you have to do, per https://www.law.cornell.edu/cfr/text/15/740.13, is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of the source code. As long as you don't change the location, you never have to worry about it again.

The regulation even notes that simply providing source code on a public website does not constitute export to a prohibited country.

It's really not a big deal.

(Note: I am not a lawyer; this does not constitute legal advice)

Re: OpenSSL after Heartbleed

#37

Post by zeveb »

mSparks wrote: post #3

For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple…

It's yet another in a long line of bugs due to C. It is, of course, possible to have bugs in every language. Even in a theoretical bug-free language it'd be possible to flawlessly implement a buggy algorithm or standard. But some languages make some sorts of bug difficult, and others make them easy: C is in the latter group.

I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Caml? Lisp?) would yield far more secure software than C. There are issues with relocatable memory and zeroing of keys, but those are, I think, addressable at the implementation level.

Re: OpenSSL after Heartbleed

#38

Post by wbond »

dom0 wrote: post #6
TwoBit wrote: post #4

Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstr…

I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20…

> Cryptography on Linux (or - on most platforms) is still in a bad shape.

Having worked with Windows and OS X crypto layers, OpenSSL, CryptoPP and libtomcrypt, I think that generally cryptography is in bad shape almost everywhere.

The libraries that are trying to improve the cryptography aspects tend to run into the issue that algorithms in heavy use are unsupported. The libraries that do support algorithms in heavy use tend to have poorly written code, convoluted APIs, or bad documentation.

I have a huge amount of respect for everyone doing work in this space. When things are working, most people ignore it, but when sometimes goes wrong, everyone is mad at you. I would imagine there isn’t a whole lot of motivation for most.

Re: OpenSSL after Heartbleed

#39

Post by acqq »

zeveb wrote: post #37
mSparks wrote: post #3

For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple…

It's yet another in a long line of bugs due to C. It is, of course, possible to have bugs in every language. Even in a theoretical bug-free language it'd be possible to flawlessly implement a buggy algorithm or standard. But some languages make some sorts of bug difficult, and others make them easy: C is in the latter group. I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Ca…

I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of the potential users. The Rust community doesn't have to implement all the functionality of Open SSL, but if it would produce at least just a proof of concept (e.g. just a minimal set of algorithms) which would prove both the capability to achieve the same speed and the provably higher security, that would be, I think, a huge start.

That would mean not wrapping the whole OpenSSL library in Rust calls but having some as minimal as possible, the tightest of the tightest loops implemented in ASM and everything else in clean and "secure" (not downgraded to the C freedom) Rust which would also pass the benchmarks and be capable to be called "on the high level" from the C code to which that library could be linked (probably the Rust code would not use GC or if it would it would have to be some so simple and minimal one that it would work by eventually calling the C malloc for bigger blocks and cause no different delays than the good written C). Not easy but I think theoretically possible for Rust. Once it would be achieved, implementing other algorithms would be possible to be done by different people and organizations.

I guess in order to achieve these goals the language designers would have to directly decide to support them, but I'd be glad if the status is already different. But I really believe that would be a huge argument for Rust: being provably more secure than C and achieving ability to implement effective drop-in replacements for C security libraries. Is it too high a goal?

I don't know how far we are from something like that, but maybe some Rust insider can estimate? What's still missing and how far we are from the point where what I described would be possible to implement?

Re: OpenSSL after Heartbleed

#40

Post by bch »

wbond wrote: post #38
dom0 wrote: post #6

Earlier quoted context omitted.

I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20…

> Cryptography on Linux (or - on most platforms) is still in a bad shape. Having worked with Windows and OS X crypto layers, OpenSSL, CryptoPP and libtomcrypt, I think that generally cryptography is in bad shape almost everywhere. The libraries that are trying to improve the cryptography aspects tend to run into the issue that algorithms in heavy use are unsupported. The libraries that do support algorithms in heavy…

I don't know about CryptoPP, or your application of encryption, but wasn't libtomcrypyt a well-intentioned but wholly poor attempt at re-presenting crypto to developers? Is it even widely used? I came to it by way of libtommath, but recall feeling pretty quickly tomcrypto was not a crypto solution.
Post reply on HN