
OpenBSD has started a massive strip-down and cleanup of OpenSSL - Serow225
https://lobste.rs/s/3utipo/openbsd_has_started_a_massive_strip-down_and_cleanup_of_openssl
======
ary
In the past I was part of an attempt to make asymmetric crypto easier to use
for a commercial product. My role was to help design the product (simple,
collaborative file sharing; you've heard it before) and to let the experts
ensure the crypto was used properly. What drove me absolutely nuts was the
level of paranoia and uncertainty around the safety of the libraries and
algorithms used. The available experts were confident in the concepts, but
feared every implementation. "Par for the course" you might say, but the
status quo around OpenSSL and other libraries is unacceptable.

From an application developer's perspective crypto libraries look like a
lightning rod even for the experts. No one wants to get too involved or make
recommendations lest they back the wrong horse (admittedly an easy thing to
do). So __kudos __to the OpenBSD team for rolling up their sleeves and
attempting to build a solid foundation for the future.

I'd be happy if OpenSSL is simply fixed. I'd be overjoyed if there was a solid
crypto system underneath an OpenSSL compatible API that gives us a path
towards an open source, reusable _crypto platform_.

~~~
chubot
Do you know about NaCl (by DJB)? It doesn't implement SSL, but it is a very
easy to use library for asymmetric crypto.

[http://nacl.cr.yp.to/box.html](http://nacl.cr.yp.to/box.html)

Can any crypto experts comment on whether it is feasible / how much work it is
to implement SSL on NaCl? Maybe the issue is that NaCl doesn't support all the
ciphers you need.

~~~
ary
I do, and I hope to give it a try in the latest product I'm building. Like
everyone else I'd prefer to see some expert validation of NaCl before I put a
ton of trust into it. That said DJB's track record is pretty good in my eyes
(I _liked_ the design of qmail, a lot).

~~~
wbl
I've examined it, and you can fuzz comp against tweetnacl. It does the right
thing generally and tests against test vectors in the build process.

------
thrownaway2424
Unfortunately it's going to be difficult to have much confidence in a huge
edit of OpenSSL since OpenSSL is almost devoid of meaningful tests. It would
be very easy for one of these "resolve merge conflicts" changelists to contain
an error of the goto fail; goto fail; variety.

~~~
clarry
Obviously there's always a risk that something slips through. However it's not
just a huge edit, it's also a huge review. And that is made so much easier
when a ton of junk is removed from the code base, and the style is changed
towards readable.

~~~
thrownaway2424
When I do code reviews I read the tests first. How can you review code with no
tests?

All the bugs in OpenSSL to this date have been reviewed by someone.
Unfortunately those people haven't been veteran industry programmers but
rather academics and "hero" types who think the kinds of things in OpenSSL are
good code. We can only hope that OpenBSD folks can clean it up a bit but I'm
not hopeful, because OpenBSD is just a different tribe of "hero" programmers.

~~~
clarry
> When I do code reviews I read the tests first. How can you review code with
> no tests?

Please grow out of this religion if you care about robust, secure and well
written software.

You can look and see what are the types of things that get fixed in OpenBSD.
Tests are not going to tell you that code works around safety measures built
in to the OS. Tests are not going to tell you that the code uses time as
entropy to seed RNGs. Tests are unlikely to tell you about the subtle integer
overflows or out-of-bounds accesses that attackers can exploit. Tests are
unlikely to tell your daemon will ungracefully fail due to fd exhaustion while
serving a larger amount of requests on a loaded system. Tests are not going to
tell you there are deceivingly familiar looking functions with surprising
return values that will confuse people. Tests are not going to tell about bad
style and code smell that makes life harder for anyone working on or looking
at the code.

There are so many things that are hard or impossible to test, but which are
vital to handle right if you're doing anything robust and secure. In fact you
could construct a test for some of these things, in theory, but in practice
you never will. And you certainly never will unless you have actually read the
code, because all these things are issues within implementation details inside
the black box; you _must_ read the code (and understand the underlying
platform) to even become aware of these issues.

Sure, tests are really useful for catching some specific issues. But there is
so much more. Tests are somewhat like compiler warnings: often extremely
helpful, but even totally insecure crap can compile cleanly. And it is
possible to write good code even if you're not using the smartest compiler to
compile it.

If you wish to learn how to review code with no tests, I recommend you read
the C language chapter from The Art of Software Security Assesment[1].
Actually read the entire book. Then go through the commit logs in some project
-- such as OpenBSD, who've been doing it for almost 20 years -- and see what
kind of issues they find and fix.

[1]
[http://ptgmedia.pearsoncmg.com/images/0321444426/samplechapt...](http://ptgmedia.pearsoncmg.com/images/0321444426/samplechapter/Dowd_ch06.pdf)

~~~
jerf
On the other hand, there's more to testing than traditional unit testing in
which a programmer enumerates a series of cases and verifies that what they
think should happen (which may or may not even be correct) happens.

There's fuzz testing. There's QuickTest-like testing, which is tricky in this
sort of situation, but powerful if you take the time. There's static analysis,
which are basically a form of automated testing. In fact, static analysis
_can_ in fact test some of the things you claim can't be tested. Some of the
other things are also more testable than you are saying, such as resource
exhaustion, which can be both simulated via injection or via simply exhausting
resources in the test case.

Further, even the relatively-weak guarantees that traditional unit testing can
provide are a _foundation_ for further analysis. What's the point of analyzing
a bit of code for whether or not it uses entropy correctly if you miss the
fact that the code is straight-up _buggy_? Given the demonstrated difficulty
of writing code even before it's _security_ code without solid testing, this
is hardly the time to be claiming that testing isn't necessary.

This strikes me as another iteration of the Real Man argument ("Real Men write
in assembler" being one of the originals). The truth is we need all the help
we can get because we humans aren't very good at programming in the end... and
of _all the places_ I'm not inclined to accept the Real Man argument, it's in
security code. This is the sort of code that ought to be getting covered by
two or three separate static analysis tools, _and_ getting reviewed by skilled
developers, _and_ getting fuzz tested, _and_ getting basic unit tests.

~~~
clarry
No Real Men arguments here. I did not claim testing isn't necessary. I just
wanted to challenge the blatantly religious attitude of pretending or
believing that a particular form of testing (one with clearly written tests
the poster above me would actually read) is all there is and that you cannot
review code otherwise. You definitely can, and must.

As far as I am concerned, all techniques that help improve code are welcome
and even necessary. This includes testing, manual review, static analysis,
etc.

------
ParadisoShlee
"Removal of all heartbeat functionality which resulted in Heartbleed"

Instead of simply fixing the bug and moving on, we're decided to assume the
whole thing is tainted and burn it alive like a depressed teenager at the
salem witch trials?

or is the heartbeat and IETF RFC considered suspicious and the heartbeat
extension offers us nothing?

~~~
jerf
In addition to kansface's point, I'd observe it's a _very_ recent addition. We
made it a long way without it.

There's a quote referenced so often it has become a cliche: "Perfection is
achieved, not when there is nothing more to add, but when there is nothing
left to take away." by Antoine de Saint-Exupery. I think it's sometimes over-
applied, but in the case of crypto software, it really fits. In a sense, the
heartbeat code got unlucky and hit the mega-anti-jackpot, disproportional to
its "actual" risk... but there _was_ risk in adding it, and even before we
know the outcome it would have, somebody really should have been asking hard
questions about whether the reward justified the risk. I imagine there's a lot
of other bits of the code where the risk/reward tradeoff suggests removal. You
can look at much of what has already been trashed from that point of view. For
instance, if you have no real need to support a particular defunct
architecture, why carry around its code? It has no benefit, but non-zero risk;
toast it.

~~~
colechristensen
An good engineer's time should be spent more on taking away than on adding.

~~~
cls59
I think Colin Percival put it best in his blog post about Heartbleed:

"The most secure code in the world is code which is never written; the least
secure code is code which is written in order to comply with a requirement on
page 70 of a 100-page standard, but never gets tested because nobody enables
that option."

------
guelo
Is this fork a vote of no confidence in the OpenSSL team? Is it guaranteed
that this fork will be used in OpenBSD? Could this fork be used in Linux? Will
they be cooperating with OpenSSL by sending them bug reports etc?

~~~
copergi
>Is it guaranteed that this fork will be used in OpenBSD?

It already is used in OpenBSD. The changes are being made in the OpenBSD
source tree.

~~~
imthatguyama
As a Linux fan who has been hearing good things about FreeBSD, will this work
out of the box on FreeBSD?

~~~
copergi
I think it will require a bit of tweaking, but I would expect the other BSDs
to adopt it once it is reasonably complete.

------
astrodust
"Removal of MacOS, Netware, OS/2, VMS and Windows build junk"

There's surely code in this project older than some of the developers working
on it.

~~~
hkphooey
Or maybe only gray-haired curmudgeons are working on this... CVS is quite a
high entry barrier for young trendy Githubbers!

~~~
mrweasel
I'm actually really impressed what so many of the OpenBSD developers can
delete/reformat/edit the OpenSSL code at the speed they seem to be working
right now and not run into issues with CVS. One awesome thing about CVS is
cvsweb ( which is a separate thing, I know), I much prefer browsing around,
diffing and viewing changes in cvsweb compared to say GitHub or Bitbucket.

Sort a side note: OpenBSD really seems to have picked up speed after they
fundraising. It wonderful to see the money has been so well spent.

~~~
astrodust
Sorry, there's nothing awesome about CVS, especially not cvsweb.

If you want a git client that's graphical, there's dozens to choose from, many
of which do a lot of what cvsweb does and more.

You can also create your own Gitorius
([https://gitorious.org/](https://gitorious.org/)) server and view changes
there before pushing to the upstream. It's like your own personal GitHub.

It is wonderful to see improvements. It's just that a refined CVS workflow is
downright awful compared to the default git one.

Being able to git clone, monkey around with your own branches, and never need
commit rights is a _huge_ deal for those looking to work with and improve your
software.

------
geerlingguy
This will be interesting to watch; I hope OpenBSD can do for OpenSSL what they
did for OpenSSH—clean it, refine it, repackage it, and make it even better,
ready for a new decade of use. I published a blog post which mentions how
OpenBSD transformed SSH into the de-facto remote administration standard it is
today just this morning[1].

I think this will be good news!

[1] [https://servercheck.in/blog/brief-history-ssh-and-remote-
acc...](https://servercheck.in/blog/brief-history-ssh-and-remote-access)

~~~
clarry
_Even though passwords are sent in the clear, ..._

------
ekianjo
Linking a lobster thread on HN, instead of the original link? Why would you
want to do that?

~~~
Serow225
I know it's unusual, but in this case I thought it was justified because the
original BSD CVS link offers little context of what's going on unless you
parse the changelog, whereas the lobster thread has a good summary by jcs.

------
protomyth
OpenBSD Journal[1] points out "To clarify, not all of the cryptographic
engines were removed; the padlock and aesni engines are still in place."

1)
[http://undeadly.org/cgi?action=article&sid=20140415093252](http://undeadly.org/cgi?action=article&sid=20140415093252)

------
bazzargh
Finding it easier to read through the commit log here than in cvsweb:

[http://freshbsd.org/search?q=libssl](http://freshbsd.org/search?q=libssl)

~~~
protomyth
That is a pretty nice way to track the changes. I see some of the comments are
getting ranty
[http://freshbsd.org/commit/openbsd/58777eed1cff7c5b34cbc0262...](http://freshbsd.org/commit/openbsd/58777eed1cff7c5b34cbc026278f730176a6dbc2)

------
Corrado
"OpenSSL must die, for it will never get any better." \- PHK
[http://queue.acm.org/detail.cfm?id=2602816](http://queue.acm.org/detail.cfm?id=2602816)
A pretty good, recent look at OpenSSL code and how it can be improved.

------
LeoNatan25
Good. Another look at any code after a long period often yields various
degrees of improvements due to a different perspective at the later date.

~~~
LukeShu
This isn't "another look"; OpenSSL is not affiliated with OpenBSD/OpenSSH,
despite the similar name. This is OpenBSD forking OpenSSL.

Someone at the linked URL humorously commented "I hope the new version is
called OpenOpenSSL."

~~~
LeoNatan25
? Did you think I assumed "similarity" due to "Open" in the title? It is
"another look". Another look can come from original writers, yes, but often a
second pair of eyes brings a different perspective that is almost always
beneficial.

~~~
LukeShu
It came across that way. You mentioned "after a long period", and whatnot.

------
eikenberry
Excellent PR move on the part of OpenBSD. This should definitely improve their
donations and work.

------
PythonicAlpha
Understandable reaction, when it can be seen how people that wanted to have
all the newest features in their product (newest TSL features in this case)
shoot themselves into their foot while others that stayed longer with the old
(proven) version where save ...

That is one reason for the popularity of Debian: (at least in the past) they
did not jump on any new bandwagon immediately. Other distributions have much
newer software, but also the newest bugs.

------
jordanthoms
OpenBSD has a great security record, definitely excited to see what they can
do if they take over OpenSSL maintenance.

------
uuid_to_string
Who knows, maybe one day we'll be able to install OpenSSL without having to
first install Perl?

IMO, this a symbol of OpenSSL's unreasonable complexity.

OpenSSL is a default system library yet the user cannot compile it with only
default system libraries.

(OpenBSD has added perl to their userland but this is not universal across
other UNIX-like OS.)

Where are the compile-time options to turn things off?

The compile process has apparently become so "challenging" that the developers
could not figure it how to do it easily without using perl.

------
wiz21
I don't know much about OpenSSL but what I know for sure is that refactoring
the code itself might not be enough. There must be some process involved to
keep track of what was refactored, what was not, enforce rigorous testing,
systematically review the code, and make sure all of that is publicly
available (when I look at the website, that information is nowhere to be
found)

------
gioele
That list misses a an important bullet point:

* Added dozens of tests.

------
gopalv
Removal of MacOS/Windows junk?

Is this going to be an openbsd only fork (I guess linux will get a build of
some sort as well).

~~~
astrodust
I'm taking this to mean MacOS as in MacOS 9 and prior, not OS X which is
unrelated. Building for MacOS was always an ugly ordeal.

~~~
duskwuff
Most likely, yes.

I wouldn't be surprised if a lot of the "Windows" support code is of similar
age, and thus was actually only needed to support pre-NT Windows.

------
JimmaDaRustla
We take for granted the "modern" security tools and libraries.

But at the same time, one would typically assume that something as large as
OpenSSL has been reviewed and tested...

------
midas007
Appending to the PHK on the OP link, it would be nice to be able to randomly
choose amongst several crypto implementations.

------
nnq
...still waiting for an article about a team of super-heroes starting to
rewrite OpenSSL in Haskell

~~~
nicolast
You mean
[http://hackage.haskell.org/package/tls](http://hackage.haskell.org/package/tls)
?

------
tiquorsj
Yay! Now OpenBSD can introduce a massive security bug. /s

~~~
estebank
They are long overdue for one =)

------
orblivion
Wow, this is what the Internet runs on?

------
Qantourisc
TLDR; but in my opinion the bug is causes by using C, use well test container
structures/functions, like those who test the bound of the container during
runtime. Those brave enough could disable the bound-checking at compilation
for performance gains.

------
splicer
How about adding "completion of our manpages" or "making our website less
shitty" to that list? See
[https://www.openssl.org/docs/](https://www.openssl.org/docs/)

~~~
na85
Hmm, no I'd rather them make a quality product than work on their website.

The last thing OpenBSD or OpenSSL needs is a whack of totally-useless js on
their website.

~~~
thrownaway2424
Documentation would be a HUGE help to the code quality of OpenSSL because
someone would have to actually sit down and describe its ghastly interface.
Whoever it was would get about half way through it and then stop and say
"Wait, what? Seriously?"

~~~
duaneb
The only other codebase I've seen that's remotely as hairy as OpenSSL is GCC's
gnarly mess. (I've heard it's improved since I looked a few years ago.) And
that's notoriously engineered to be difficult as possible to contribute
without giving back; I can't imagine what OpenSSL's excuse is. Any sane
programmer would have cold sweats even if they understood the implementation
because it's so difficult to figure out and verify what the fuck is going on
internally with any speed.

Documentation would help, but a good cleanup would make provided documentation
much less necessary. Crypto may be difficult to understand, but with clean
coding practices and formal verification (even on an audit workflow level)
would be a much better investment, IMHO.

