Hacker News Reader

Comment by kevan | Hacker News Reader

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

View on HN

I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code.

The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language.

Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...

Writing C is like handling venomous snakes. There's lots of people that think they can do it safely and, for the most part, they usually do. But if you do it for long enough, you're going to get bitten. All it takes is the smallest mistake. And when that happens, you better hope it's not in the wild, because if left untreated, it gets bad in a hurry.

Rust can't mature fast enough.

The nice thing about C has always been how close you can get to the hardware, while still having some sensible flow control. The bad thing about C is how close you need to get to the hardware.

I really think that everyone serious about programming should learn C, to the level where they can read parts of the Linux kernel or something, but never actually deploy C code to a production environment. It's not a "must" -- not a requirement to be a good programmer or developer at all -- but you'll understand something much closer to the hardware than you will in a more modern language. Just don't expose that program to an adversary if you can avoid it, because that proximity to the hardware makes a single mistake catastrophic.

Plus, if you ever need to do embedded work, you often don't have a choice other than C.

Your concerns are legitimate, but I wouldn't jump to blaming C here. Yes, this deals with memory management, but the cost presented is not conceptually difficult. We can rephrase this issue in any other context and not raise a C argument---you have some set of resources that need to be closed (file descriptors, database connections, etc), and you forget to close it. I was writing a daemon in Node.js for my employer and during development I noticed that it leaking file descriptors until the kernel killed it. That can happen in any language.

Nothing against the programmer; these things happen. But I wouldn't say because of C in this case.

C makes these sort of problems more common and occupy more time/energy/source code than they need to. The language doesn't try to help the programmer with even the most basic of these sort of resource management problems. Most modern languages offer tools to handle some subset of them (e.g. GC for memory in managed languages, or destructors for memory and more in C++/Rust), reducing the burden on the programmer for normal resource life cycles and hopefully making it easier to handle the abnormal cases better.

Sure, it's not generally possible for a language to perfectly manage every resource all the time, but this doesn't mean we should just give up and throw away computer assistance in cases when we can have it.

C is an important language, but there's no need to look at it through rose-coloured glasses.

Would Rust be a good alternative? Can you get constant time calculations in Rust?

LLVM isn't great for constant time guarantees, so you need to do the assembly yourself, last I checked.

Well, there is this: https://github.com/klutzy/nadeko

Right. As the README says, LLVM makes this hard. So nadeko handles the codegen itself.

"... but it is not how anyone in their right mind writes C."

If I were going to place blame (I think a better approach is to skip that and just solve the problem), then I would blame developers, not the language.

To me, the code you are criticizing is very "regular" -- it follows predictable patterns. I find it easier to follow than most other C code I read.

More importantly I believe it is worth following. Obviously he is doing something right as reliability, performance and paucity of bugs shows.

All this despite not being in the "right mind", whatever that means.

I wish all the programs I am forced to use were written with such care.

I wish all C was written with such care as well. I just wish they had less pointer arithmetic, less one-character variables and was commented, you know, at all...

I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. I still think that will happen.

> I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation.

Yes and no.

No in that LibreSSL aims to be mostly drop-in compatible with OpenSSL (modulo deprecations/removals) and OpenSSL has a very complex API exposing lots of internal gunk to the user, so moving to a non-C implementation may not be possible at all.

Yes because there's a related `libtls`[0] project which aims to define more abstracted API (with the reference implementation being done on top of libressl). As POC, tedu has/had an implementation of the API using golang's TLS stack[1], and noted that you could build the same on e.g. the OCaml/Mirage TLS stack[2]. If `libtls` fulfils its promises, it would become much easier to swap TLS stack and indeed move to non-C implementations.

[0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/... HN discussion: https://news.ycombinator.com/item?id=8572029 (some comments may not apply anymore IIRC the discussion was the initial API which has been extended since)

[1] http://www.tedunangst.com/flak/post/goreSSL

[2] https://mirage.io/blog/introducing-ocaml-tls

If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution?

Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely.

I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!

Well for a start lua not having integers would be an issue when implementing cryptographic primitives. The second issue is while lua is relatively lightweight, carrying a full lua runtime for each of the libraries you're using would still get unwieldy and costly, adding ~400K to each embedder according to the About page ("Under 64-bit Linux, […] the Lua library takes 414K")

Apologies. I should have referenced Lua 5.3 instead as it has both integer and bitwise operator support. This should satisfy the concerns regarding crypto implementation.

As for the space considerations, I have two ways to reason this:

* Wouldn't it only take up 1x414K? If you create luaSSL as a drop in replacement to OpenSSL, you'd only need one copy in your filesystem, just as you only have one OpenSSL.

* Even if you bloat your binary sizes by 414K per executable, isn't it worth it to go from "yes, it could be unsafe, we'll never know... let's wait for the next CVE" to 100% guaranteed no memory faults EVER? Nothing is free, and this could be a cheap price to pay for the guarantee of memory safety, and the implications that come with it.

Edit: wording

For crypto-primitives, you usually want them to be constant-time. This is basically impossible to do in an interpreter or a JIT, indeed optimizing compilers can and will optimize contant-time operations out so inline assembly is commonly used.

Thank you for the info!

Speed and ease of using low level techniques, probably.

Could you please summarize how djb's code is different?

Well... Someone said of his code that the only reason it is bug-free is because it scares bugs away. Large amounts of pointer arithmetic. Religious checks (heck, he even checks if printf (not fprintf) succeeds or not), and... odd (not sure if it's the right word. maybe insane is better) macros. Plenty of one letter variables.

Misunderstand me correctly, he writes solid software. He's not just a guy I would like to work with :)

laughs maniacally

is keeping score what we're interested in today?

https://www.openssl.org/news/vulnerabilities.html

If you're looking for a chart, Wikipedia is keeping score:

https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...

Whether this bug affects the upstream project is a legitimate concern, I think. It would be like worrying that a vulnerability in OpenBSD affected NetBSD, too, especially if it was found relatively close to when OpenBSD forked.

"Secure connection failed"

Reply on news.ycombinator.com