Enable TLS hostname verification by default #18874
EronWright
started this conversation in
General
Replies: 5 comments
|
The issue had no activity for 30 days, mark with Stale label. |
0 replies
|
This idea makes sense, but this change breaks user behavior. |
0 replies
|
Thanks for your explanation. Then moved to the discussion forum. |
0 replies
|
This issue is still relevant. I have wanted to submit a PIP to do this, and to make sure that all configuration names for hostname verification are the same, but I haven't had a chance. I think Pulsar should move towards enabling hostname verification by default. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Is your enhancement request related to a problem? Please describe.
Hostname verification is a critical aspect of TLS, especially when using the system-provided certificate bundle. TLS server authentication consists of two steps, a) verify the certificate is valid according to a trust chain (i.e. a certificate bundle), and b) verify that the certificate is applicable to the connection (i.e. hostname verification). See the article The Most Dangerous Code in the World for more details.
Without hostname verification, the client is willing to accept any certificate that is rooted in the certificate bundle; if you use the system bundle, any certificate from Let's Encrypt or other public issuer would suffice. For example, the client thinks it is connecting to
pulsar.apache.orgbut accepts a certificate fordomain-that-i-just-purchased.com.Pulsar disables hostname verification by default, perhaps on the assumption that a private CA is being used and thus the set of valid certificates is tightly controlled. From the docs:
Describe the solution you'd like
The enhancement request is to enable hostname verification by default, at least when using the system cert bundle. Specifically, enable verification when both are true: a) an explicit setting has not been specified, and b) a certificate bundle has not been specified. Condition (b) is for backwards compatibility purposes.
All reactions