Drop support for insecure PEM-level encryption for private keys in TLS #46980
Description
Describe the enhancement:
Some users might still be storing their TLS private keys in PEM files using the insecure and deprecated PEM-level encryption (PKCS#1 key structure, RFC 1423 encryption). This encryption does not support authentication and is vulnerable to padding oracle attacks that can let an attacker recover the plaintext of the private key.
This affects all the output.*.ssl.key config parameters:
https://www.elastic.co/docs/reference/beats/filebeat/configuration-ssl
Although it's a full responsibility of the user to choose a secure encryption for their private keys, on our side we still let to use this insecure encryption in our TLS library:
Naturally, we also support a secure encryption with authentication for private keys passed in the PKCS#8 structure:
This task is to remove support for encrypted private keys in the PKCS#1 structure that use the PEM-level encryption defined by RFC 1423.
We should also print a well-readable error message on Beat startup when PKCS#1 structure is used for encrypted private keys. The message should clearly explain that the PEM-level encryption available for the PKCS#1 structure is insecure and might lead to the content of the private key to be exposed.
The message should also explain that the customer should rather use the PKCS#8 structure instead because it supports secure key encryption with authentication (defined in PKCS#5).
Describe a specific use case for the enhancement or feature:
Customers might be unaware that they are still using insecure encryption for their private keys when setting up TLS in Beats. We should properly notify them and drop support for such insecure encryption.