ResourceHandleSoup::handleUnignoredTLSErrors currently checks whether TLS errors are ignorable or not.
In case of a redirection, the URL that is used to do the check is the initial request URL, not the URL used after the redirection.
This may cause two potential issues:
1. If a certificate is added in the list of authorized certificates for a domain N1, it will not be found in case of a redirection from a domain N2 to N1.
2. If TLS errors are skipped for a domain N1, TLS errors will also be skipped for a domain N2 in case of a redirection from N1 to N2.
EWebLauncher has this behavior when enforcing TLS errors checks (setIgnoreSSLErrors(false)) and registering a self-signed certificate to a specific domain.
This bug can be examplified by modifying EWebLauncher setup.
For instance by inserting the two following lines at the end of ewk_main.cpp::_ewk_init_body:
A potential fix in ResourceHandleSoup::handleUnignoredTLSErrors could be something like:
- String lowercaseHostURL = handle->firstRequest().url().host().lower();
+ String lowercaseHostURL = String::fromUTF8(soup_uri_get_host(soup_message_get_uri(d->m_soupMessage.get()))).lower();
Although a test would probably be good to have (?), I wonder how it can be implemented within the current test framework.
The correct behavior is to perform separate checks for TLS errors before and after the redirect, with the original and new domain. I don't doubt this was broken four years ago, but I'm pretty sure that is what happens nowadays. ResourceHandleSoup::handleUnignoredTLSErrors does not exist anymore. Can this bug be closed?
no problem closing it.
I guess only manual testing is available right now....
Just to clarify it. What we do now is monitor the tls-errors property of the SoupMessage, ans check for errors when it changes cancelling the load in such case.