TLS client is build with InsecureSkipVerify

[aman-bansal]

InsecureSkipVerify while defined TLS client is not recommended in production systems. This is susceptible to man in the middle attack. Only for internal testing, this should be enabled.

Expected Behavior

One of the hidden features of TLS is hostname verification. While defining client, ServerName verification is needed to detect if there is any routing via man in the middle attack. For this to work, the client should know which server he is expecting the results. It works automatically if the hostname is matched to the server name provided in the certificate. Otherwise, we need to specify it separately.

Actual Behavior

InsecureSkipVerify is being used and thus hostname verification is skipped.

Specifications

Present in all versions

Solution / Suggestion

I believe for every scaler using TLS server name should be added as an additional trigger parameter. If not provided, we will use InsecureSkipVerify.

Let's discuss how best we can achieve this. And I would love to pick this up too.
cc. @ahmelsayed @zroubalik @tomkerkhove @turbaszek

[arschles]

https://github.com/kedacore/keda/pull/1251/files makes some progress towards this. creation of HTTP requests is limited to 1-2 points in the code

[tomkerkhove]

Is this just for RabbitMQ @aman-bansal?

[aman-bansal]

No it's something that has been present at every place where we work with TLS. RabbitMQ, Kafka, Metric api everywhere.

[marchmallow]

We could help support it for Redis TLS too

[arschles]

#1251 (comment) for related discussion on this

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[arschles]

It seems that this issue should stay open. Our TLS clients should, by default, not be built with InsecureSkipVerify

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.

[debu99]

looks like rabbitmq doesn't support it yet until now