Live data from Hacker News

Just how bad is OpenSSL? (2012)

lists.randombit.net

31–40 of 50 posts

Re: Just how bad is OpenSSL? (2012)

#31
"For instance it doesn't have everything you need to validate certificates..."

Yet it has all the CA crap thrown in, via the overloaded openssl binary. As "examples". And according to the documentation, not even "correct" illustrations of how libssl should be used.

Encryption and authentication are two separate problems.

Just because you figured out a way to encrypt a message does not mean you have also figured out how to a way to send it to only the correct recipient... over an insecure network. (Insecure not only in the sense of "plaintext" but in the sense you are not in control of much of anything - routing, PKI infrastructure, etc.)

It seems to me that one would want to solve the authentication problem first, and then move on to encryption.

This comment shows that for proponents of using SSL on the public web, it's been the other way around. Authentication was never sorted out.

When it comes to authentication, all due respect to the OpenSSL authors, SSH has provided a better attempt at a solution than any implementation of PKI using SSL/TLS.

And one more thing, how many ciphers does a user really need? As we've heard time and again, many of them are not even "safe" to use. Some of the alternative SSL libraries have wisely removed them. But I guess OpenSSL is append only?

Re: Just how bad is OpenSSL? (2012)

#32
post #15

After the string of vulnerabilities, I know that OpenSSL got a wave of investment. I'm curious how much of this still stands today.

look at the list of CVE's since[0], as well as tedunangst's commentary on his blog[1]. they pair up nicely.

0. http://www.cvedetails.com/product/383/Openssl-Openssl.html?v...

1. http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

Re: Just how bad is OpenSSL? (2012)

#33
post #15

After the string of vulnerabilities, I know that OpenSSL got a wave of investment. I'm curious how much of this still stands today.

I got a few thousand dollars of that money as a security bug bounty.

OpenSSL fixed the problem quickly, but one year on still haven't accepted the regression test for the issue. It would be amusing if it wasn't so horrifying.

Re: Just how bad is OpenSSL? (2012)

#34

OpenSSL is pretty bad. After reading about some of the stuff that lead the the libressl fork, I wouldn't trust it with my lunch money. Sure, the algorithms are good, but as far as the code's concerned, Heartbleed was the tip of the iceberg.

There's a saying, "don't roll your own crypto," and it's good advice.

In the case of openssl, you might be better off rolling your own. At least the vulnerabilities you end up with are different than the ones that the rest of the world has.

Re: Just how bad is OpenSSL? (2012)

#35
post #15

After the string of vulnerabilities, I know that OpenSSL got a wave of investment. I'm curious how much of this still stands today.

look at the list of CVE's since[0], as well as tedunangst's commentary on his blog[1]. they pair up nicely. 0. http://www.cvedetails.com/product/383/Openssl-Openssl.html?v... 1. http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

20 vulnerabilities found so far in 2016 in openSSL, that's basically saying that the codebase is still not secure.

Re: Just how bad is OpenSSL? (2012)

#36
post #21

Earlier quoted context omitted.

You're presuming man pages are primarily meant to serve as a reference. But I rarely need man-pages as a reference†. Most of the time, if I'm looking up a man-page for something, it's because I've just installed a new package that sounded like it would solve a problem and then did a dpkg-query(1) to find out what binaries came with it—or used apropos(1) to find a relevant binary already installed—and now I want to kn…

>You're presuming man pages are primarily meant to serve as a reference. They are.

Let me rephrase: you assume that it makes sense for manpages to continue serving primarily as a reference—that this is the primary use-case people have for the standardized program documentation that ships with their distro packages.

Shipping a reference to a binary with that binary may have made sense before the internet. But nowadays, it's the opposite.

• Complex programs with many options have (sometimes dozens of) websites documenting them thoroughly. (Try searching with any search-engine for "wget mirroring", for example; the number and complexity of the results is overwhelming.)

• Meanwhile, for the simple "corner-case" programs, you really hope that they shipped with docs—because seemingly nobody else out there on the web cares to bother documenting them. With a lot of these little programs, the only web doc you can find are, in fact, online mirrors of their man-page.

For the popular-and-complex programs, man-pages are just redundant, because everyone will document what they did to achieve whatever. But for the simple-but-weird programs—the ones for which man-pages aren't just redundancies—if the man-page doesn't give usage, then nothing is going to give usage.

Now, I can understand why man-pages for these little utilities are the way they are. These programs are usually created by a single author, so time spent writing docs is time not spent fixing bugs or scratching their itch or whatever else. And an options reference certainly is the "minimal normalized form" of documentation: it lets others brute-force combinatoric-search the space of invocations until they find some combination that Works For Them™. Basically, you can (through a lot of trial and error) generate a cookbook from an options reference. So the author probably doesn't feel a strong need to add anything beyond an options reference, because the people who really need to solve the problem their binary solves are willing to go to that effort.

But if you're a distro downstream packager, and it's your job to make your distro easy for people to use, you should have every incentive to submit upstream patches to said author, with manpage additions of cookbook example usages resulting from your trial-and-error experimentation with their program.

Annoyingly, you, as a distro packager, probably don't have time to do that trial-and-error experimentation, especially if the utility serves a niche use-case that you don't even understand. That—and not the fact that "manpages should be a reference and nothing more"—is most of the reason manpages continue to be the way they are.

Re: Just how bad is OpenSSL? (2012)

#37

Earlier quoted context omitted.

Yes man pages are usually upside-down; the examples should be right at the start and then lead to a drill-down into options. 9/10 times I end-up having to search the web for a basic introductory example. But even in big corps corps with ISO9000 accreditation there is seldom self- questioning as to whether documentation is useful rather than just ticking the box for process-completeness.

Yes! For some reason I still always type `man whatever` when I need to do something with a tool... even though I'm just presented with 50 pages of gibberish that I scroll through for a few pages then go to Stack Overflow. The problem I usually find is that man pages give equal importance to every possible flag - making really hard to figure out which elements you most likely will need to do common tasks.

Whoever answers your question on Stack Overflow likely got their information from a man page.

Re: Just how bad is OpenSSL? (2012)

#38
post #21
post #12

Earlier quoted context omitted.

No. 90% of the time, I know what I want to do, and how my tools work. I just don't remember the options are called. Having a summary of the options right there at the top is the most valuable thing in a reference.

You're presuming man pages are primarily meant to serve as a reference. But I rarely need man-pages as a reference†. Most of the time, if I'm looking up a man-page for something, it's because I've just installed a new package that sounded like it would solve a problem and then did a dpkg-query(1) to find out what binaries came with it—or used apropos(1) to find a relevant binary already installed—and now I want to kn…

> absolutely horrible command-line UX-design, like tar(1) or ps(1) or rsync(1)

how would you improve their design

Re: Just how bad is OpenSSL? (2012)

#39
post #36

Earlier quoted context omitted.

>You're presuming man pages are primarily meant to serve as a reference. They are.

Let me rephrase: you assume that it makes sense for manpages to continue serving primarily as a reference—that this is the primary use-case people have for the standardized program documentation that ships with their distro packages. Shipping a reference to a binary with that binary may have made sense before the internet. But nowadays, it's the opposite. • Complex programs with many options have (sometimes dozens of…

Man pages are written (ideally) as the authoritative reference on your system, where you can go to find information. That sort of thing needs to exist somewhere, it has a clear use case.

An ideal man page is concise, informative, and complete. Learning to read them is like learning to read scientific literature: a pain, but once you figure it out, you're at a higher level.

Re: Just how bad is OpenSSL? (2012)

#40
post #17

Earlier quoted context omitted.

i interpreted this as: this was written by security experts (cryptographers), not expert programmers. this means the algorithms are generally ok, but the implementation is wacky (and issue prone).

It was also written by cryptographers who for years asked for support, and got barely enough to keep the server running let alone live off it. Meanwhile the world and his wife joined in with feature requests and complaints about things they didn't like, but mostly without offering to help. So it doesn't surprise me that unit testing, documentation, code review etc. weren't a top priority for spending more unpaid hour…

I'll partly agree with that. Mostly even. I draw the line at expecting a security-critical library intending widespread adoption at least follow secure coding guidelines if nothing else. It really doesnt take much effort vs what was already done. Tiny fraction of it.

That plus the larger trend of developers ignoring basic, good practices is why I critique the project a bit. Plus, LibreSSL team illustrated my point nicely by doing 10x what I expected in a very short time with no pay.

Post reply on HN