Icinga Web DB - do not verify cert or give different certs per redis connection

Hello Community,

I am stuck a bit on configuring encrypted Redis connection with two masters.
I was wondering if there is an undocumented option to not verify the tls certificates, due to the fact IcingaDB and the Icinga2 IcingaDB feature both have it.

I found this pending PR with the configuration options:

Additional Question regarding tls verification:

right now, both possible redis connections share one certificate option, that does not seem ideal to me. Whats the best practice to deal with that?

Environment:


|Icinga Web 2 Version|2.12.5|
|director||1.11.5|
|doc||2.12.5|
|icingadb||1.2.2|
|incubator|

Kind Regards
Simon

Thanks for your post. I have created an Icinga DB Web issue out of it: Redis Configuration: Different Certificate for Connections and Insecure Mode · Issue #1281 · Icinga/icingadb-web · GitHub.

Excuse me for being pedantic. If you actively decide to not verify TLS certificates, the connection should not be considered as encrypted, but like plain text.

I have created an Icinga DB Web issue out of it

Thank you!

Excuse me for being pedantic. If you actively decide to not verify TLS certificates, the connection > should not be considered as encrypted, but like plain text.

I would differentiate between encrypted, verified and trusted here.
It was more an option I was expecting, because the other components offered it.

As a small follow up, you could place multiple CA certificates in the CA box - and Icinga DB Web will check against both. Of course, this might have security implications, depending on your setup or trust model.

And there is an “insecure” slider, it just shows up after one inserts an invalid CA PEM and Icinga DB Web fails to validate it.

With (almost) no intention to derail this topic, I would argue that encryption without verification is both insecure and dangerous. An adversary can MitM the connection with ease and you would still be under the assumption to have a “secure” line. It gives a false sense of safety.

This is described from another angle with way more words in the “Encryption is Not Integrity!” article in PoC||GTFO 20, page 62.

OT: It’s at least obfuscation :smile: