Description
Related to #832.
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.
My feeling is that the explanation in https://bugzilla.mozilla.org/show_bug.cgi?id=134402#c36 is about right...
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:
- https://bugs.python.org/issue31997#msg306240
[...]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.
- https://news.ycombinator.com/item?id=5384864