The sorry state of OpenSSL usability (2017) • Hacker News Board

Re: The sorry state of OpenSSL usability (2017)

#41

Post by [deleted] » Wed, May 29, 2019, 6:03 PM UTC

HugoDaniel wrote: post #31

ivl wrote: post #25

Earlier quoted context omitted.

You're not wrong, but there's a big middleground here. To a user without some curiosity this: LibreSSL releases contain several parts: libcrypto: a library of cryptography fundamentals libssl: a TLS library libtls: a new TLS library, designed to make it easier to write foolproof applications Various utilities such as openssl(1), nc(1), and ocspcheck(8). With libcrypto, libssl, libtls, openssl, nc, and ocspcheck all l…

I found it strange since OpenBSD is known for their excellent docs. So after opening the libressl site they have that paragraph stating the parts of the lib and links to their docs. That page works as the documentation index. Namely https://man.openbsd.org/openssl.1 Which the author was complaining about needing to use google for. Specifically the https://man.openbsd.org/openssl.1#GENRSA seems well document. Forks ar…

[deleted]

Re: The sorry state of OpenSSL usability (2017)

#42

Post by toast0 » Wed, May 29, 2019, 6:06 PM UTC

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)

Based on Ted's take on FIPS [1], I don't think that's likely to happen anytime soon.

I'm constantly thankful that I'm able to work somewhere that I don't have to worry about other people's bogus security checkboxes.

[1] https://marc.info/?l=openbsd-misc&m=139819485423701&w=2

Re: The sorry state of OpenSSL usability (2017)

#43

Post by compuguy » Wed, May 29, 2019, 6:07 PM UTC

upofadown wrote: post #38

snazz wrote: post #22

Earlier quoted context omitted.

This is not a priority at all for the OpenBSD developers. Most of them are Canadian anyway, as I understand it.

That is actually understating it. The libressl developers purged the code base of the FIPS stuff as part of a policy. From here: * https://marc.info/?l=openbsd-misc&m=139819485423701&w=2 "Note that FIPS mode isn't just worthless, it's actively harmful."

Unfortunately if you work with the US Government, there are situations where FIPS mode is required. This is why RHEL and CentOS still use OpenSSL...

Re: The sorry state of OpenSSL usability (2017)

#44

Post by JdeBP » Wed, May 29, 2019, 6:08 PM UTC

guitarbill wrote: post #7

avoidwork wrote: post #2

`openssl help` ... the macos version hides the `Invalid command '--help'; type "help" for a list.` message.

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.

Re: The sorry state of OpenSSL usability (2017)

#45

Post by CiPHPerCoder » Wed, May 29, 2019, 6:08 PM UTC

My question is: Why are you trying to use RSA at all?

It's 2019! I can't think of anyone who seriously recommends RSA anymore. Switch to elliptic curve cryptography, where footbullets like a 512-bit RSA key offer aren't even on the table.

Re: The sorry state of OpenSSL usability (2017)

#46

Post by compuguy » Wed, May 29, 2019, 6:09 PM UTC

toast0 wrote: post #42

mhb_eng wrote: post #17

Earlier quoted context omitted.

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)

Based on Ted's take on FIPS [1], I don't think that's likely to happen anytime soon. I'm constantly thankful that I'm able to work somewhere that I don't have to worry about other people's bogus security checkboxes. [1] https://marc.info/?l=openbsd-misc&m=139819485423701&w=2

I agree. Until someone convinces NIST to modernize and/or improve the FIPS standard, people who work with government agencies are stuck with it...

Re: The sorry state of OpenSSL usability (2017)

#47

Post by gbrown_ » Wed, May 29, 2019, 6:09 PM UTC

brynet wrote: post #20

> Unfortunately, http://www.libressl.org/ won’t help you either, because there literally isn’t any documentation of LibreSSL. This is untrue. The front page contains links to the documentation inline, OpenBSD/LibreSSL converted all of OpenSSL's awful perlpod documentation to semantic mdoc(5) markup, and even wrote new man pages for functions completely undocumented by OpenSSL. See Ingo Schwarze' EuroBSDCon 2018 talk…

Yup, I pointed this out last time this was posted.

https://news.ycombinator.com/item?id=16025063

It would be nice if the author revised that remark.

Re: The sorry state of OpenSSL usability (2017)

#48

Post by parliament32 » Wed, May 29, 2019, 6:10 PM UTC

All of these complaints are MacOS problems. On my Debian laptop, "openssl --help" actually displays some help (despite --help not being a real flag), "man openssl" works as expected, and "openssl genrsa" uses a 2048-bit modulus... and "openssl verison" confirms it's actually openssl.

Re: The sorry state of OpenSSL usability (2017)

#49

Post by nocman » Wed, May 29, 2019, 6:11 PM UTC

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!

I do think it would be a good idea for the libressl.org site to put a link on the left "sidebar" with the text "Documentation" (which shows a page of links at minimum), just to make it obvious where to find it.

That was the first thing I looked for, and it took me a while to realize that the links "libcrypto", "libssl", etc on the main page were links to the documentation for each command. In fact, the only reason I found them was the fact that your post said "It _is_ linked to in their front page.", so I went back to find them.

Yeah, if I'd needed it right now, I would have figured it out eventually, but I think making it a bit more explicit (for lack of a better term) would be a good thing.

Re: The sorry state of OpenSSL usability (2017)

#50

Post by tialaramex » Wed, May 29, 2019, 6:11 PM UTC

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 all). They've got stamps from every decade (you need current stamps). They have rare stamps (you don't want to pay extra!) and they have lots of used stamps (no longer valid).

Until relatively recently OpenSSL would default to creating CSRs by urging you to fill out largely irrelevant X.500 Distinguished Name and not even mention SAN dnsNames even though most users who want a CSR want it for a TLS server (e.g. web server) where the former is unimportant and the latter is vital.

When it comes to writing TLS client software you probably know the name of the server you want to talk to. A sane API would let you tell the library this once and do all the rest for you. But OpenSSL reflects the interesting (to stamp collectors) half dozen different places that server names are involved in different versions of the protocols, not this sane but boring API.

If you are a student of cryptographic history OpenSSL is great. If you are a application developer it's... poor. If you're a regular end user it's awful.