The sorry state of OpenSSL usability (2017)

https://jameshfisher.com/2017/12/02/the-sorry-state-of-openssl-usability/

by anchpop • 7 years ago

161 79 7 years ago

avoidwork• 7 years ago

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

guitarbill2• 7 years ago

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/information-technology/2014/04/tech-...

JdeBP5• 7 years ago

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.

bromonkey2• 7 years ago

manpages for openssl (`man openssl`) exist on Linux + Solaris + BSD, this seems like a mac usability issue to me...

CaliforniaKarl2• 7 years ago

Apple deprecated OpenSSL in macOS some time ago, directing people to their Core Crypto framework instead.

See http://stackoverflow.com/questions/7406946/why-is-apple-depr... for more info and links

mls-pl• 7 years ago

it's not quite true - on latest macOS (10.14.5), on openssl based on LibreSSL 2.6.5 there's complete man page available - but, the funniest thing, it's dated on... today

CaliforniaKarl2• 7 years ago

I think this should be retitled to "The sorry state of OpenSSL usability [on macOS]", because the author is using the built-in OpenSSL on macOS (which, as is eventually discovered, isn't actually OpenSSL).

If you want to use OpenSSL on macOS, I suggest using the OpenSSL provided either in Brew or in MacPorts. That will give you a fully-functional setup (including help and man pages).

tedivm2• 7 years ago

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

kevin_b_er• 7 years ago

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 you to use 'help'

3. man pages do exist. Just not installed by apple like author expected

4. and stop forking OpenSSL; BSD project forked it and Apple wants BSD over anything else because they can put the software in their closed platforms. Even if libressl were on the up and up, Apple's still got a version from 2016 installed.

Those are all Apple problems, not openssl problems.

lol7682• 7 years ago

  $ 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 format - one of DER PEM
  -in infile       input file
  -out outfile     output file (output format is always DER)
  -i               indents the output
  $ openssl genrsa -out foo.pem
  Generating RSA private key, 2048 bit long modulus (2 primes)
  ......................................................+++++
  .......................+++++
  e is 65537 (0x010001)

tomxor4• 7 years ago

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] https://www.libressl.org/releases.html

mtgx• 7 years ago

Use Noise then:

https://noiseprotocol.org/

https://github.com/mcginty/snow

eloy• 7 years ago

And stop forking OpenSSL; you’re just making things worse.

Yeah no. OpenBSD developers did a really good job by improving the codebase of OpenSSL. See also some of their presentations: https://www.libressl.org/papers.html

crescentfresh2• 7 years ago

by improving the codebase of OpenSSL

Just to clarify: LibreSSL forked OpenSSL [1]. By definition they did not improve the codebase of OpenSSL.

[1] https://en.wikipedia.org/wiki/LibreSSL

zwerdlds• 7 years ago

Didnt most of their changes get merged back?

minusf• 7 years ago

libressl has documentation. it's an OpenBSD project so you use the man pages.

http://man.openbsd.org/openssl

mhb_eng• 7 years ago

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)

snazz• 7 years ago

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

rkeene2• 7 years ago

Yes, this is why I had to stick to OpenSSL for my Linux distribution even though I would have preferred LibreSSL.

CiPHPerCoder5• 7 years ago

If anyone really wanted FIPS 140-2 compliance for libressl they should pony up the money to get it certified instead of complaining about it on message boards.

toast02• 7 years ago

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

IcePic• 7 years ago

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.

ergothus2• 7 years ago

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 definitely sounds like Apple is NOT the problem in this case (though certainly not helping)

gipp• 7 years ago

Yeah the accessibility of the manpages was clearly the least significant objection by far, but yours is the first comment about anything else.

tialaramex• 7 years ago

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.

ergothus2• 7 years ago

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.

beefhash• 7 years ago

OpenSSL decided to use a “512 bit long modulus”, the default. We’re told: “don’t roll your own crypto; instead trust standard tools like OpenSSL”. The modulus length is a good example of why: a wrong value results in a trivially breakable key, and you the user shouldn’t need to know what the right value is. So OpenSSL chooses a sensible modulus length for you.

Checking the OpenBSD man page for the LibreSSL genrsa, it does seem to generate 2048-bit RSA keys by default[1].

Perhaps Apple just stuck with an older default (for backwards compat) or perhaps this wasn't changed yet in the old version of LibreSSL that Apple uses?

[1] https://man.openbsd.org/openssl#GENRSA

JdeBP5• 7 years ago

2.2.7 came out in May 2016. The switch to 2048 bits was in May 2014.

* https://github.com/libressl-portable/openbsd/commit/30eb68d7...

brynet• 7 years ago

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 "Better documentation - on the web and for LibreSSL"

https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf

https://youtu.be/jwfN7S1-fRA

And earlier writeups from 2016.

https://undeadly.org/cgi?action=article;sid=20161215221715

It's been a long road to improve the documentation, and it's substantially better than OpenSSL.

ivl• 7 years ago

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 links pointing to man.openbsd.org/x does not scream documentation. The words 'documentation' or 'manual' appear nowhere on the libressl home page.

They are undoubtedly present, but unless you click around assuming those aren't links to individual components, you wouldn't think so at a glance.

thepangolino• 7 years ago

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.

JdeBP5• 7 years ago

They're rather working on the assumption that readers know that anything with a "(1)" or an "(8)" after it is a reference to a user manual. This is a very common thing in BSD doco, and in Unix doco more generally.

For experienced Unix users this is likely to be true. It's something that one just learns. For novice users, it is less likely.

HugoDaniel• 7 years ago

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 are just the way open source works and if documentation could be better then we are all free to contribute to it.

gbrown_• 7 years ago

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.

closeparen• 7 years ago

The Go crypto package is really a treat. I found it scary and incomprehensible to do anything with certificates using the OpenSSL command line, convenience wrappers notwithstanding. Adam Langley’s work shows what a reasonably ergonomic and approachable interface for this domain could look like. Turns out that issuing certificates doesn’t have to be dark magic.

garyb2• 7 years ago

Just tried openssl genrsa on my Mac:

openssl genrsa Generating RSA private key, 2048 bit long modulus

openssl version LibreSSL 2.6.5

So maybe install Mac updates?

JdeBP5• 7 years ago

As pointed out in this discussion elsewhere, this is an article written in 2017 and never updated.

* https://github.com/jameshfisher/jameshfisher.com/commits/mas...

CiPHPerCoder5• 7 years ago

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.

bromonkey2• 7 years ago

This article was written years ago

CiPHPerCoder5• 7 years ago

Oh! It really should have [2017] in the title, then.

recursive• 7 years ago

Why are you trying to use RSA at all?

Probably because you have to use something, and it's not obvious which things have footbullets and which don't.

CiPHPerCoder5• 7 years ago

https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

https://paragonie.com/blog/2017/06/libsodium-quick-reference...

https://libsodium.gitbook.io/doc/bindings_for_other_language...

It's a lot easier in 2019 than it was years ago.

x38iq84n• 7 years ago

Sometimes it is a necessity to accommodate for various networking gear as load balancers, wireless controllers etc as RSA may be the only thing that they support.

parliament32• 7 years ago

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.

low_key• 7 years ago

Sure, the commands are difficult to digest. Where it gets truly awful, though, is trying to write a program that uses the openssl library.

GTP• 7 years ago

If on macOS openSSL is replaced by LibreSSL isn't OpenSSL's fault, and I also think that the title "The sorry state of OpenSSL usability" isn't right since it's actually talking about LibreSSL. By the way I've just ran "man openssl" on a Linux box and got the manual for OpenSSL, so I'm thinking that this could be more a problem of macOS than OpenSSL. Of course I agree that the online docs should say if something is deprecated or is using a default value that is no longer safe, but the rest of the article doesn't seem well made to me

notacoward• 7 years ago

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 pass them in for the library to call at random times. Weird WANT_READ/WANT_WRITE nonsense that makes integration with a bog-standard poll/select loop more difficult. It's like the OpenSSL developers think SSL is the main thing your program should be doing and you're lucky they let any other functionality exist in the same program. The phrase "fractal of bad design" was originally invented for PHP but applies to OpenSSL just as much.

alias_neo• 7 years ago

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.

The sorry state of OpenSSL usability (2017)

Related Stories