RESOLVED CONFIGURATION CHANGED 113755
[Soup]TLS error bad certificate check in case of redirections
https://bugs.webkit.org/show_bug.cgi?id=113755
Summary [Soup]TLS error bad certificate check in case of redirections
youenn fablet
Reported 2013-04-02 00:35:07 PDT
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.
Attachments
youenn fablet
Comment 1 2013-04-02 00:39:21 PDT
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: WebCore::ResourceHandle::setIgnoreSSLErrors(false); WebCore::ResourceHandle::setHostAllowsAnyHTTPSCertificate(“domain N1”); 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. Any advice?
Michael Catanzaro
Comment 2 2017-05-16 15:33:02 PDT
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?
youenn fablet
Comment 3 2017-05-16 15:47:53 PDT
no problem closing it. I guess only manual testing is available right now....
Carlos Garcia Campos
Comment 4 2017-05-17 00:11:24 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.