Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sorry state of OpenSSL usability (2017)

jameshfisher.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: The sorry state of OpenSSL usability (2017)

#71

Post by tomxor »

clarry wrote: post #70
tomxor wrote: post #69

Earlier quoted context omitted.

Debian (OpenSSL), man page is present, and 2048 mod is default: openssl genrsa -out private_key.pem Generating RSA private key, 2048 bit long modulus (2 primes) These are all either MacOS or LibreSSL problems. This may not even be a LibreSSL problem since the version the author is using is 3 years old [1] MacOS userland is always so ancient, the other bits of BSD userland are even worse as far as I remember. [1] http…

> These are all MacOS | LibreSSL problems Just MacOS. > If you want documented examples, everyone should know this is where man pages suck in general, they are usually just reference manuals. OpenBSD is generally pretty good about providing some useful examples in man pages. The libressl man page has examples too, for genpkey at least.

I meant OR (|) as a do not _know_ having only tried OpenSSL, updated to clarify this - I thought using bitwise operators would be safe here, I guess it doesn't work with english.

RE man pages, I am speaking generally (as i said), i know nothing of OpenBSDs man pages, and it doesn't matter, my point was not that LibreSSL or OpenSSL man pages suck for examples, but that it's a bad premise for an argument against Open/LibreSSL.

Re: The sorry state of OpenSSL usability (2017)

#72

Post by alias_neo »

notacoward wrote: post #68

If you think the user interface is bad, try the programmer interface. OMG. Layer upon layer of nonsensical objects to initialize and chain together, each with a bazillion options and no decent documentation about which few are secure. No decent interface for getting the specifics about an error. Not thread-safe unless you create your own array of locking functions (which must meet barely-documented requirements) and…

The developer interface is _much_ worse than the user interface. At least the user interface had shell completions to guide your guess work. As you suggested, having to initialise a bunch of things in some undisclosed order is bordering on meddling with the dark arts, good luck tearing it all down again safely. Then let's say you want to streaming-encrypt something on the fly, good luck understanding the correct way to chain BIOs and what exactly the behaviour for seeking, buffering, writing, closing, opening, decrypting, reading, popping BIOs and then working with the remainder of the chain, before pushing a BIO back on is.

I wrote a steaming data encryptor a little while back using openssl, just in C, it works fine now but the majority of my reading was existing implementations on the web and some out-of-date blogs coupled with some, sometimes-correct documentation and just pain trial-and-error paired with my good old friend Valgrind.

Unfortunately, in some industries it's go-FIPS-or-go-home, so we don't even have the choice of using a fork or an alternative at times.

Re: The sorry state of OpenSSL usability (2017)

#73

Post by ergothus »

tialaramex wrote: post #50
ergothus wrote: post #18

A lot of comments here about LibreSSL and Apple vs OpenSSL. Which is fine, that was my immediate reaction. But do the criticisms re:weak defaults, unlabeled deprecated commands, and uninformative output apply? Because I'll admit - every time I have to use (some version of) openSSL I google for the command I need and blindly use it. The commands are cryptic and meaningless. If this is true outside of LibreSSL, that de…

As someone who actually understands what is going on here I only partly agree. The commands aren't meaningless, but OpenSSL approaches the problem from a perspective that isn't what any ordinary user will want. Imagine you want to post a package to Brazil. You see a shop selling postage stamps - perfect. But of course such a shop is for stamp collectors. They've got lots of Brazilian stamps (you don't need those at a…

> You see a shop selling postage stamps - perfect. But of course such a shop is for stamp collectors.

That is a fantastic analogy and I'm stealing it for my own uses!

Thanks for the great breakdown.

Re: The sorry state of OpenSSL usability (2017)

#74

Post by tomxor »

tedivm wrote: post #16
kevin_b_er wrote: post #13

Earlier quoted context omitted.

> Users matter: try doing some usability testing. Try adding some help text and man pages, instead of hijacking the wiki webpage of a different SSL project. And stop forking OpenSSL; you’re just making things worse. 1. Apple is not usability testing this 3 year old version of a fork of openssl, because they're not supporting it at all. 2. help text not available because its an apple supplied fork. openssl does tell y…

1. The OpenSSL API hasn't changed, and if Apple changed it on their own that would break more things 2. The issue the author complained about was `openssl --help` not working, and it doesn't work on any platform (because he got the command wrong). `openssl help` does work on OSX (I literally just tested it). 3. Yeah, that's the one issue we agree is an Apple issue. 4. Apple didn't make LibreSSL. Other systems besides…

> 4. Apple didn't make LibreSSL. Other systems besides Apple use LibreSSL, and the authors complaints about their lack of documentation are relevant regardless of what Apple does.

Other systems probably upgrade their copy of BSD userland more than once a decade... especially if they are the richest company on Earth.

There are probably 100 other user rants to accompany this for all the other massively out of date bits of BSD on MacOS.

Re: The sorry state of OpenSSL usability (2017)

#75

Post by tomxor »

clarry wrote: post #66
tedivm wrote: post #16

Earlier quoted context omitted.

1. The OpenSSL API hasn't changed, and if Apple changed it on their own that would break more things 2. The issue the author complained about was `openssl --help` not working, and it doesn't work on any platform (because he got the command wrong). `openssl help` does work on OSX (I literally just tested it). 3. Yeah, that's the one issue we agree is an Apple issue. 4. Apple didn't make LibreSSL. Other systems besides…

> 4. Apple didn't make LibreSSL. Other systems besides Apple use LibreSSL, and the authors complaints about their lack of documentation are relevant regardless of what Apple does. No, this is specifically Apple's fuck up. The documentation is right there on OpenBSD! It pretty much always was. I have a live system running OpenBSD older than this rant, and the man pages are there. The default modulus is 2048 too.

> I have a live system running OpenBSD older than this rant, and the man pages are there. The default modulus is 2048 too.

That's pretty hilarious if Apple changed the default from 2048 to 512!

Re: The sorry state of OpenSSL usability (2017)

#76

Post by IcePic »

mhb_eng wrote: post #17
minusf wrote: post #12

libressl has documentation. it's an OpenBSD project so you use the man pages. http://man.openbsd.org/openssl

Unfortunately, libressl is not FIPS 140-2 compliant, so you can't leverage it for open source development of secure applications for the US government (though this is more to do with the certification headache than a fault of libressl itself)

I guess this also matters: https://en.wikipedia.org/wiki/FIPS_140#Criticism It is very easy to see how this in practice lessens security.

Re: The sorry state of OpenSSL usability (2017)

#77

Post by lol768 »

JdeBP wrote: post #62
lol768 wrote: post #61

Earlier quoted context omitted.

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.04 Release: 19.04 Codename: disco $ openssl --help Invalid command '--help'; type "help" for a list. $ openssl help 2>&1 | head -n 3 Standard commands asn1parse ca ciphers cms crl crl2pkcs7 dgst dhparam $ openssl help asn1parse Usage: asn1parse [options] Valid options are: -help Display this summary -inform PEM|DER input form…

And as pointed out in this very discussion at https://news.ycombinator.com/item?id=20043375 and https://news.ycombinator.com/item?id=20042633 , they do not even apply to MacOS.

Seems that, regardless of platform, this was only really relevant back in 2017.

Re: The sorry state of OpenSSL usability (2017)

#78

Post by floatingatoll »

kevin_b_er wrote: post #13
tedivm wrote: post #8

Earlier quoted context omitted.

Outside of the man page issue all of the complaints from the author apply to all platforms that have openssl.

> Users matter: try doing some usability testing. Try adding some help text and man pages, instead of hijacking the wiki webpage of a different SSL project. And stop forking OpenSSL; you’re just making things worse. 1. Apple is not usability testing this 3 year old version of a fork of openssl, because they're not supporting it at all. 2. help text not available because its an apple supplied fork. openssl does tell y…

Happily, it will likely be removed in the next macOS, at which point anything still dependent on it will break utterly until either updated to use SecureTransport or to bundle OpenSSL.

I predict a popular tool favored by the HN community will break, leading to a highly-upvoted front page post that instructs everyone on how to reinstall the shim wrapper using an unsigned tarball from an unsafe non-Apple source and zero patches to that tool from us to make it use the modern macOS-provided library instead.

Re: The sorry state of OpenSSL usability (2017)

#79

Post by pwinnski »

PuercoPop wrote: post #35
thepangolino wrote: post #28

Earlier quoted context omitted.

So what your saying the issue is libressl should put a link to the documentation on their front page? Sounds like a fair request. Perhaps someone should send them an email to let them know. That being said, you put a finger on the main issue most security and privacy tool have: user friendliness.

It _is_ linked to in their front page. The article is complaining about not finding documentation for the openssl command while literally linking to the front page that contains a link to said the documentation. They don't even have to Google, just read!

Not just read. There are 23 or so links on that page, roughly one-fourth of which lead to documentation pages, non-obviously. Of course, anything is obvious once you know it, but clearly it isn't obvious enough, or we wouldn't be having this discussion!

So they don't have to search, just read and click on links until they hit one that looks like a man page.

Re: The sorry state of OpenSSL usability (2017)

#80

Post by guitarbill »

JdeBP wrote: post #44
guitarbill wrote: post #7

Earlier quoted context omitted.

that's kind of annoying. at the same time, this also underscores the issue of usability. why not alias "--help" to "help"? yes, i know even critical open source projects are extremely underfunded. perversely, the lack of funding meant that there weren't enough people to review code, which meant contributing was difficult - at least according to this article from 2014 shortly after heartbleed: https://arstechnica.com/…

Note that part of the problem is the erroneous assumption that "--help" is ubiquitous. It isn't, in practice. It's a GNUism that one does not find very often in the BSD world.

fair enough, but still: how much effort would it be to support both?
Post reply on HN