You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given a web::http::http_client constructed with "https://www.example.com/foo/bar", PR #832 means that in http_client_asio.cpp, the handle_cert_verification function applies RFC 2818 matching to "www.example.com" as expected.
However, with a URL of "https://www.example.com./foo/bar", the trailing dot is not discarded and thus fails to match a cert with a SAN or CN that doesn't have the trailing dot. Most issued certificates seem not include the trailing dot in these fields.
Yes, it's ok to match "www.example.com." (trailing) to the cert with "www.example.com" (no trailing)
It's also OK to match "www.example.com" (no trailing) to the cert with "www.example.com." (trailing)
It's NOT OK to match "mybank.com" (as entered in the URL bar) to "mybank.com.mycompany.com" (as resolved by DNS).
This could be worked around in the application layer, i.e. by setting the Host header, but it feels like it can only be solved in the name-matching code, i.e. either in the way boost::asio::ssl::rfc2818_verification is called by the C++ REST SDK layer or possibly in the way it's implemented by the ASIO/SSL layer?
More commentary on this issue (for other implementation stacks) is at:
[...]the ssl module is the wrong place to address the issue. You must keep SNI TLS extension, HTTP Host header, and hostname for SAN matching in sync. [...] The issue must be solved in HTTP layer because the HTTP layer is the only place that can affect the HTTP Host header and SNI.
Related to #832.
Given a
web::http::http_client
constructed with "https://www.example.com/foo/bar", PR #832 means that inhttp_client_asio.cpp
, thehandle_cert_verification
function applies RFC 2818 matching to "www.example.com" as expected.However, with a URL of "https://www.example.com./foo/bar", the trailing dot is not discarded and thus fails to match a cert with a SAN or CN that doesn't have the trailing dot. Most issued certificates seem not include the trailing dot in these fields.
My feeling is that the explanation in https://bugzilla.mozilla.org/show_bug.cgi?id=134402#c36 is about right...
This could be worked around in the application layer, i.e. by setting the
Host
header, but it feels like it can only be solved in the name-matching code, i.e. either in the wayboost::asio::ssl::rfc2818_verification
is called by the C++ REST SDK layer or possibly in the way it's implemented by the ASIO/SSL layer?More commentary on this issue (for other implementation stacks) is at:
The text was updated successfully, but these errors were encountered: