Bug 208806 – [Curl] WKCertificateInfoGetVerificationError function doesn't return an error code when the browser accesses https://wrong.host.badssl.com

• Component: Platform
• Status: RESOLVED FIXED

[Takashi Komori]

wrong.host.badssl.com is test site which provides wrong cert.
When curl port accesses the site, browser warns the cert is wrong but when the browser calls WKCertificateInfoGetVerificationError, it doesn't return error code.

This is because the process of TLS verification has two stages below, and curl port checks only the result of the first stage.
stage 1) OpenSSL checks the validity of the certification itself and the certification chain.
stage 2) curl checks the content of the cert against common name.

wrong.host.badssl.com provides wildcard cert for *.badssl.com and the invalidity is checked on stage 2.
Now curl port doesn't use the result of stage 2, so WKCertificateInfoGetVerificationError function doesn't return error code.

[Takashi Komori]

Created attachment 393025 [details]
Fix the return code WKCertificateInfoGetVerificationError function returns.

[Takashi Komori]

(In reply to Takashi Komori from comment #1)
> Created attachment 393025 [details]
> Fix the return code WKCertificateInfoGetVerificationError function returns.

This patch fixes the bug by checking the result of the result of validation on curl layer using curl_easy_getinfo.

Unfortunately we couldn't make tests for this change.
We think tests for the patch should be added to API tests (TestWebKitAPI/Tests/WebKit/curl/Certificates.cpp), but the reproduction of this bug is difficult in API tests because it only occurs accessing sites which have wrong certs.

We added some code which shows return code of WKCertificateInfoGetVerificationError function on Server Trust Evaluation Request Dialog.
For now, checking non-zero return code on the dialog is the only way to check the patch is working.

If there is some good way to test the patch, please teach us.

[Darin Adler]

We could and probably should configure some erroneous certificates locally in the web server we use to run tests. Not sure the whole range of options we have to map DNS all to that single server with different certificates; I think it makes sense for WebKit testing to include that and it’s worth some effort.

[Takashi Komori]

(In reply to Darin Adler from comment #3)
> We could and probably should configure some erroneous certificates locally
> in the web server we use to run tests. Not sure the whole range of options
> we have to map DNS all to that single server with different certificates; I
> think it makes sense for WebKit testing to include that and it’s worth some
> effort.

We will try to find how to test bad certs. Thank you for your comment.

[Kenji Shukuwa]

Pull request: https://github.com/WebKit/WebKit/pull/6618

[EWS]

Committed 256827@main (58dd451692d4): <https://commits.webkit.org/256827@main>

Reviewed commits have been landed. Closing PR #6618 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/102506886>