-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Agent using Host header for SNI server_name #37104
Comments
The only reason I can think of is that this approach allows you to lazily query the server by its IP to avoid DNS resolution, without defining host and servername separately. Which sounds like a bit of a bad idea to me, tbh |
SNI should be the conceptual equivalent of virtual hosting for HTTPS, so I imagine the reason could be for providing that behavior. I can't say if it's right or wrong, though. |
#22389 Found an issue that has been discussed since 2018. |
Due to how nodejs works, if you try to call an HTTPs endpoint like inference-staging.discovery.wmnet with a custom HTTP Host header (like enwiki-goodfaith.revscoring-editquality-goodfaith.wikimedia.org) the TLS servername will be set with said value. This means that without proper SANs, there will be TLS hostname validation errors reported by nodejs. This is what's happening when ChangeProp tries to contact LiftWing, due to this nodejs "feature": nodejs/node#37104 This change is meant to test the new SANs on the staging endpoint first. Bug: T327302 Change-Id: I7822f4e41e111537ea2e6208d9b47b5192d488d4
What steps will reproduce the bug?
I'm not 100% sure that this is a bug, but it was surprising behavior that is different from any other http clients I've looked at (curl, python's httplib, nginx).
If you make an HTTPS request specifying a
host
header that is different from the requesthost
, theservername
used for SNI will be set to the value of thehost
header, unless thehost
header contains an IP address or you explicitly pass aservername
in the agent options.node/lib/http.js
Lines 1086 to 1092 in b0c0111
What is the expected behavior?
This was very surprising to me as the
host
header is part of the HTTP layer, and theservername
belongs to the TLS layer, and I have never seen a client behave this way. I would have expected thehost
(not thehost
header) to be used as the defaultservername
.For example using curl:
As you can see, the certificate is accepted:
If we do the same thing in Node, the certificate will be rejected as the certificate host name does not match the server name that we send:
This will result in
[ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames
.Changing this so that the
host
is used as the defaultservername
instead of thehost
header is a small and simple change, but my question would be if this is done intentionally, and if so, why?Additional information
The text was updated successfully, but these errors were encountered: