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

61–70 of 80 posts

Re: OpenSSL after Heartbleed

#61

Post by steveklabnik »

acqq wrote: post #57
steveklabnik wrote: post #56

Earlier quoted context omitted.

See https://crates.io/crates/ring , which is a fork of boringSSL, porting the C over to Rust. Endgame is 100% Rust and asm. https://crates.io/crates/rustls is a TLS library built on top of ring .

Can it be used from C, e.g. C that statically links the library? Does it depend on the GC? What is the current speed? Thanks! Edit: Re "just know they exist" (meaning libraries) in the answer: That's why I started the topic, the people who use only C wouldn't have chance to try the library unless the people who know enough Rust give something explicit that works and can be actually tested in linkability, functionalit…

  > Does it depend on the GC?
Rust has no GC.

I am not sure about your other questions, as I haven't used them directly, I just know they exist. :) The former is possible, but I don't know if the authors have done any work on that.

Re: OpenSSL after Heartbleed

#62

Post by nickpsecurity »

acqq wrote: post #60
nickpsecurity wrote: post #59

Earlier quoted context omitted.

Ocaml is only one that uses GC IIRC. Others produce C.

Links please? Any actual library produced and linkable, even with just one algorithm? I can't find it behind that Ivory link? Thanks! Edit: also thanks for explaining the nature of the solutions you mention ("custom jobs").

I dont have those. They're used for custom jobs by people who know the language. Im not in that category. ;)

Re: OpenSSL after Heartbleed

#63

Post by nickpsecurity »

acqq wrote: post #60
nickpsecurity wrote: post #59

Earlier quoted context omitted.

Ocaml is only one that uses GC IIRC. Others produce C.

Links please? Any actual library produced and linkable, even with just one algorithm? I can't find it behind that Ivory link? Thanks! Edit: also thanks for explaining the nature of the solutions you mention ("custom jobs").

Wait, I just remembered COGENT people did a case study by doing ext2 filesystem in COGENT. They have COGENT on Github. The filesystem source or binary might be in repo(s) of COGENT team allng with other examples. So, Google that.

Re: OpenSSL after Heartbleed

#64

Post by sidlls »

pjmlp wrote: post #55
sidlls wrote: post #48

Earlier quoted context omitted.

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.

You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from. Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen. Also most of the C tools that he…

I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract.

Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.

Re: OpenSSL after Heartbleed

#65

Post by duneroadrunner »

pjmlp wrote: post #47
duneroadrunner wrote: post #23

Earlier quoted context omitted.

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!

Well that's just it, use of the sanitizers is not up to the developers, it's a build-time option. The TOR guys have enabled them when building firefox[1]. But apparently some of their debugging features actually introduce potential vulnerabilities themselves so they're not really appropriate for deployed executables. Yet.

[1] https://blog.torproject.org/category/tags/tbb-hardened

Re: OpenSSL after Heartbleed

#66

Post by duneroadrunner »

nickpsecurity wrote: post #44
duneroadrunner wrote: post #23

Earlier quoted context omitted.

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

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1].

Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives.

Maybe these new and improved choices will make a difference. We can dream, can't we? :)

[1] https://blog.torproject.org/category/tags/tbb-hardened

Re: OpenSSL after Heartbleed

#67

Post by burntsushi »

sidlls wrote: post #64
pjmlp wrote: post #55

Earlier quoted context omitted.

You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from. Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen. Also most of the C tools that he…

I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract. Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Sa…

> Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.

At some point, it has to be human vetted. I don't see another way. The key advantage is the ability to build safe abstractions from unsafe components.

Will people abuse unsafe? Absolutely. Is it a lot better than the alternatives? IMO, absolutely. :-)

In my own experience, unsafe is rarely needed. I've only ever used it for ffi and lightly in very performance critical areas of code. The regex library, for example, has almost no unsafe. Its only use is to get rid of bound checks inside the DFA's inner loop.

The most (non-ffi) unsafe I've ever used is in a snappy compression library, where most of it was a means to more efficiently shuffle bytes around without paying for memcpy (using unaligned 8 byte or 16 byte loads/stores).

There is a pretty strong tendency in the Rust community to avoid unsafe. Some libraries advertise themselves as having "no unsafe code" as a selling point precisely for the dangers you've hinted at: humans make mistakes.

Re: OpenSSL after Heartbleed

#68

Post by brians »

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 5-10 person-years of work, depending on where you draw the finish line, "just" to do something like BoringSSL. miTLS is at least five times that, and even there I'm assuming you start with people like Bhargavan and Fournet---both world class, people who've spent decades getting to the point where they can do this with 25 person-years.

That shows up on the balance sheet of the security-infrastructure team even of Microsoft or Google.

Re: OpenSSL after Heartbleed

#69

Post by DasIch »

sidlls wrote: post #48
DasIch wrote: post #5

Earlier quoted context omitted.

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.

If you work on real objects made of metal and wood with dangerous tools like chain saws. There are a variety of protective measures you can take like guards, clothing and so on. These things don't provide guarantees safety under all conditions, they don't guarantee good design, objects that have no mistakes or that will never behave badly when used.

And yet, despite all of that not using these protective measures is considered by every reasonable person as incredibly stupid and worthy of a darwin award. This goes so far that there are laws that regulate this.

Nevertheless somehow when it comes to software all of that goes out the window. There is risk to other peoples money, privacy and potentially their lives? Who gives a shit? It doesn't make everything a 100% safe so let's use decades old tools that are difficult to learn are horrible to work with, allow for a huge number of completely preventable mistakes to happen, that we know happen often.

In any other context people would never come up with such a criticism. It would be considered ridiculously stupid to the point that some might think you're being sarcastic and making a joke and once they discover they not, they'd ask if there are some mental problems that might require attention.

Rust and languages that go into that direction don't solve all our problems and that's completely irrelevant.

Re: OpenSSL after Heartbleed

#70

Post by DasIch »

mSparks wrote: post #25
DasIch wrote: post #24

Earlier quoted context omitted.

So? Nobody disagrees on the fact that there is a problem. Putting blame on people won't solve the problem. It will piss people off. People you want on your side, enthusiastically solving the problem. Your attitude is actually dangerous and counterproductive to solving the problem. This toxic culture is a big part why we are in this mess. Who in their right mind would want to try work on OpenSSL to improve it while be…

It's not a case of blaming. Its a case of choosing https://www.libressl.org/ or https://www.openssl.org/ Applying best practice development processes or Pretending someone else can do it all for you, and you can "bolt it on" at the end. The article lists: Future plans and lessons learned: At the top of the list for future development is support for TLS 1.3. Like adding yet another protocol to the already hacked mess…

LibreSSL is only better because it does less and much more human attention is wasted on producing bug free C code. That's an improvement but it's quite limited.
Post reply on HN