tls: Add descriptions for x509v3 alt name verification (tls.verify_hostname)

[cosmo0920]

Corresponding to fluent/fluent-bit#8966.

[patrick-stephens]

Is there a reason we default to not verifying the alternative name? This seems counter to an expectation of secure by default.

[patrick-stephens]

Slightly different wording to below.

[cosmo0920]

Is there a reason we default to not verifying the alternative name? This seems counter to an expectation of secure by default.

Once, I implemented this feature as a forcibly style, I just though such way. Because hostname verification is mostly required for TLS connections to prevent malformed hostname attached instances. However, we got realized that there is many issues in certificates for kubelet. So, preserving the backward compatibilities, we need to disable by default.

[patrick-stephens]

Is there a reason we default to not verifying the alternative name? This seems counter to an expectation of secure by default.

Once, I implemented this feature as a forcibly style, I just though such way. Because hostname verification is mostly required for TLS connections to prevent malformed hostname attached instances. However, we got realized that there is many issues in certificates for kubelet. So, preserving the backward compatibilities, we need to disable by default.

Is this just to handle kubelet specific things then? I'd expect tls verify for everything else, e.g. outputs, etc., so can we just add a special config for kubelet usage to disable it?

[cosmo0920]

Is there a reason we default to not verifying the alternative name? This seems counter to an expectation of secure by default.

Once, I implemented this feature as a forcibly style, I just though such way. Because hostname verification is mostly required for TLS connections to prevent malformed hostname attached instances. However, we got realized that there is many issues in certificates for kubelet. So, preserving the backward compatibilities, we need to disable by default.

Is this just to handle kubelet specific things then? I'd expect tls verify for everything else, e.g. outputs, etc., so can we just add a special config for kubelet usage to disable it?

Hmm.., I see. For 3.x line, we need to restore the behavior. But it's reasonable to verify certificates as much as possible in 3.1.
@edsiper Can we break the behavior around certificates in Fluent Bit 3.1? It's reasonable to verify certificates except for filter_kubernetes.

[cosmo0920]

Oh, merged my PRs as-is. Also, users complains in in_forward and filter_kubernetes. This is because our network stack is not dumped for its error status with human readable errors. So, we need to restore the behavior. For TLS client, we can print the error message from OpenSSL's certificate verification. But, for server, we didn't get how to print an error with human readable modifications.