To provide a bit more background (not sure of your level of expertise) -
A human being makes up a somewhat memorable encryption password, hopefully not too easily guessable, and typically comprising printable characters only e.g. “myLibrem5Backup” 
A “key derivation function” (KDF) converts the encryption password into an X-bit key (whatever length key is actually required by the encryption algorithm being used).
Human beings aren’t very good at making up random passwords (not uniformly distributed and not much entropy). It may be viable for an attacker to iterate through all passwords that a human would actually choose and maybe quickly eliminate that key by decrypting the first encryption block. That will take far far less time than simply iterating over all X-bit keys. (Even though the vast majority of X-bit keys can never arise from the KDF algorithm, due to lack of entropy in the original password, the attacker has no way of telling which X-bit keys can arise and which cannot.)
A KDF is designed to be hard on the CPU - take a non-trivial amount of time on a current CPU but not so much time that the user experience sucks or even that network protocols time out waiting for keys to be derived - and ideally be difficult to implement in a GPU. The KDF has to mung the password hard but not too hard. To maintain strength over time a KDF typically has a parameter that is the number of iterations that are applied.
According to the internet, openssl uses as the default KDF something that is home brew (similar to PBKDF1) with an iteration count of 1.
Anything “home brew” should be considered at least a little bit suspect (but as this is open source it can be retrospectively reviewed by experts around the world, and no doubt has been).
PBKDF1 having been superseded by PBKDF2 should be considered suspect.
An iteration count of 1 is almost certainly woefully inadequate. (By way of comparison, when WiFi uses PBKDF2, it uses 4096 iterations.)