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

41–50 of 80 posts

Re: OpenSSL after Heartbleed

#41

Post by LukeShu »

vtlynch wrote: post #33
akira2501 wrote: post #18

Earlier quoted context omitted.

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?

Yes.

https://web.archive.org/web/20120805001248/http://www.openss...

August 2015 is just when they did a website redesign, which caused some URLs to change.

Re: OpenSSL after Heartbleed

#42

Post by whyever »

DasIch wrote: post #5
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…

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…

> There needs to be a move towards more constrained languages like Rust that limit the potential mistakes

It's happening: https://github.com/ctz/rustls

Re: OpenSSL after Heartbleed

#43

Post by nickpsecurity »

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 are. They just ask for significant licensing fees to cover the work they did. Licensing fees most users of cryptography have no interest in paying. ;) Others are dual-licensed with little uptake.

An early example was Guttman's cryptlib which is dual-licensed:

https://en.wikipedia.org/wiki/Cryptlib

Note: An interesting feature of it is that it embeds a security kernel that tries to ensure the algorithms are composed correctly.

Another dual-licensed one that seemed to at least have better code quality was PolarSSL used in Fox-IT's OpenVPN-NL project and partially verified by TrustinSoft's analyzer:

https://tls.mbed.org/features

MatrixSSL is another one aiming at small, efficient execution:

https://www.insidesecure.com/Products-Technologies/Protocol-...

Save the best for last in Amazon's s2. It has much potential coming from the combo of simplicity, design-for-verification, and actual reviews by pentesters:

https://github.com/awslabs/s2n

Note: There's also quite a few designed for robustness in smartcard industry. The EAL5+ one from IBM's Caernarvon team is likely to be high quality. The thing is we can't review them but we can review above code. So better to go with above. Also recall this list is of commercial replacements for SSL in addition to others' recommendations on LibreSSL, BoringSSL, etc.

Re: OpenSSL after Heartbleed

#44

Post by nickpsecurity »

duneroadrunner wrote: post #23
DasIch wrote: post #14

Earlier quoted context omitted.

I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't thi…

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://git…

I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used.

All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.

Re: OpenSSL after Heartbleed

#45

Post by nickpsecurity »

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…

They can even use a typed, assembly language if they want to have handwritten ASM and prove memory safety. Just no interest outside CompSci types.

Re: OpenSSL after Heartbleed

#46

Post by nickpsecurity »

acqq wrote: post #39
zeveb wrote: post #37

Earlier quoted context omitted.

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 th…

Already done in Ocaml for projects willing to use something other than OpenSSL:

https://github.com/mirleft/ocaml-tls

It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers. Ivory embeds a subset of C in Haskell to keep things easy to analyze and automatically safe. Parts of a SSL library could use it.

http://ivorylang.org/ivory-introduction.html

So, Haskell, LISP, and ML are already capable of replacing our SSL libraries if people choose. One is already done in Ocaml. COGENT, if people apply it to this, will take it further by having an easier-to-verify implementation in functional language with certified compilation to C or assembly.

Re: OpenSSL after Heartbleed

#47

Post by pjmlp »

duneroadrunner wrote: post #23
DasIch wrote: post #14

Earlier quoted context omitted.

I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't thi…

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://git…

I doubt anyone in C community would turn them on anyway.

They even made the "security" annex optional in C11!

Re: OpenSSL after Heartbleed

#48

Post by sidlls »

DasIch wrote: post #5
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…

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries a…

Rust guarantees safety under certain conditions. That's it. It doesn't guarantee good design, bug free code, or code that never behaves badly. This is the kind of gratuitous maligning of code written in other languages that some Rust fans engage in that I find off-putting. Rust isn't The Solution To All Our Problems.

Re: OpenSSL after Heartbleed

#49

Post by pjmlp »

nickpsecurity wrote: post #46
acqq wrote: post #39

Earlier quoted context omitted.

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 th…

Already done in Ocaml for projects willing to use something other than OpenSSL: https://github.com/mirleft/ocaml-tls It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers.…

There is also the F* version, which can be made to target C via their KreMlin compiler.

https://project-everest.github.io/

https://fstarlang.github.io/general/2016/09/30/introducing-k...

Presented at this year's ICFP conference.

https://www.youtube.com/watch?v=sP7PRHn9iEA

Re: OpenSSL after Heartbleed

#50

Post by nickpsecurity »

pjmlp wrote: post #49
nickpsecurity wrote: post #46

Earlier quoted context omitted.

Already done in Ocaml for projects willing to use something other than OpenSSL: https://github.com/mirleft/ocaml-tls It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers.…

There is also the F* version, which can be made to target C via their KreMlin compiler. https://project-everest.github.io/ https://fstarlang.github.io/general/2016/09/30/introducing-k... Presented at this year's ICFP conference. https://www.youtube.com/watch?v=sP7PRHn9iEA

I reposted your link on Lobste.rs. I noted that COGENT already was doing verified functional with certified translation to C or assembly. Also that F star to C seems to be Microsoft and INRIA's route. So, at least two projects are making it much easier to verify algorithms or protocols in functional way with C code resulting.

The other thing I noted is that most code meant for verification is designed to be easy for humans or machines. The F star and C is one of few that is easy for both. I rarely see that.

Post reply on HN