Bug 208806

Summary: [Curl] WKCertificateInfoGetVerificationError function doesn't return an error code when the browser accesses https://wrong.host.badssl.com
Product: WebKit Reporter: Takashi Komori <takashi.komori>
Component: PlatformAssignee: Takashi Komori <takashi.komori>
Status: RESOLVED FIXED    
Severity: Normal CC: Basuke.Suzuki, chris.reid, darin, don.olmstead, ews-watchlist, galpeter, Hironori.Fujii, ross.kirsling, stephan.szabo, takashi.komori, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Fix the return code WKCertificateInfoGetVerificationError function returns. none

Description Takashi Komori 2020-03-09 06:40:19 PDT 
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.
Comment 1 Takashi Komori 2020-03-09 06:48:38 PDT 
Created attachment 393025 [details]
Fix the return code WKCertificateInfoGetVerificationError function returns.
Comment 2 Takashi Komori 2020-03-09 07:09:35 PDT 
(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.
Comment 3 Darin Adler 2020-03-09 09:55:09 PDT 
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.
Comment 4 Takashi Komori 2020-03-09 20:32:15 PDT 
(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.
Comment 5 Kenji Shukuwa 2022-11-17 19:50:31 PST 
Pull request: https://github.com/WebKit/WebKit/pull/6618
Comment 6 EWS 2022-11-18 01:59:09 PST 
Committed 256827@main (58dd451692d4): <https://commits.webkit.org/256827@main>

Reviewed commits have been landed. Closing PR #6618 and removing active labels.
Comment 7 Radar WebKit Bug Importer 2022-11-18 02:00:17 PST 
<rdar://problem/102506886>