Hi Hugh,
Thanks for the comments.
Hugh McIntyre wrote:
> Alfred Peng wrote:
>> Hi Brian,
>>
>> Please see my comments below:
>>
>> On 01/07/09 10:43, Brian Cameron wrote:
>>> 2) Exactly how does WebKit fail when a user tries to access a HTTPS
>>> website. Since it is not built with HTTPS support, ARC wants to
>>> make sure that it doesn't in any way mislead the user. A user
>>> should not be misled into thinking it is working when it is not.
>>>
>>> In other words, it should be clear to the end user that when they
>>> try
>>> to visit a HTTPS website with WebKit that it doesn't work. It
>>> should
>>> also be usable, so it shouldn't just crash or similar. Does it pop
>>> up a dialog informing the user about the issue?
>> I tried to build epiphany (a browser GUI application which we don't
>> ship) with WebKit. When accessing HTTPS website, epiphany will try to
>> load the page. But only blank page will be displayed in the browser
>> window and no error dialog shows up. Users can open new tab to access
>> other normal website at the same time.
>
> According to a web search, the reason for the debatable
> "WEBKIT_IGNORE_SSL_ERRORS" option is that although WebKit (and the
> CURL that this generally uses under the covers) supports HTTPS
> including certificate checking (sometimes), there's no way in WebKit
> to popup a dialog message to the user in the same way that Firefox
> does if the certificate has errors (hostname mismatch, expired,
> signature error, etc.).
Firefox depends on NSS for certs verification. Besides, it provides a
way for users to add exception when the server side certificate fails to
verify. I doubt WebKit, as a library, should do the work to pop up a
dialog. Maybe the applications which depend on WebKit should implement this.
> There seems to be an other gotcha issue here in that WebKit apparently
> does not ship with any root certs by default, which would mean there's
> no way to end up with a passing signature. (CURL may have a default
> set of certs?) This could presumably be fixed though.
The libcurl is the HTTP backend for WebKit. It could enable OpenSSL,
gnutls or NSS for https handling and specify the CA bundle to use. From
libcurl's ARC (PSARC/2007/165), the libcurl shipped in Solaris is built
with system OpenSSL. I think it can use OpenSSL's certificate for
verification. But there is a bug: /etc/sfw/openssl/certs has no well
known CA certificates (bugster CR#6661895) so that certificate
verification isn't supported.
> The obvious solution would have been "load the page if the cert is OK,
> otherwise fail". This may in fact be the default if HTTPS support is
> compiled in in the absence of WEBKIT_IGNORE_SSL_ERRORS, although this
> is not 100% clear. It's also not clear to me if LSARC/2008/782 is
> compiled with or without CURL and OpenSSL. It does appear though that
> the WEBKIT_IGNORE_SSL_ERRORS option is for people with self-signed
> certificates who otherwise would have no way to load their pages,
> because of the above-mentioned limitation that there's no way for a
> WebKit app to pop up a dialog saying "this certificate is in error; do
> you want to load the page anyway?"
WebKit will build with libcurl which in turn links against OpenSSL.
WebKit doesn't link with OpenSSL directly.
> Internally this seems to translate as follows:
>
> const bool ignoreSSLErrors = getenv("WEBKIT_IGNORE_SSL_ERRORS");
>
> // FIXME: Enable SSL verification when we have a way of
> // shipping certs and/or reporting SSL errors to the user.
> if (ignoreSSLErrors)
> curl_easy_setopt(d->m_handle, CURLOPT_SSL_VERIFYPEER, false);
>
> The CURL documentation then says the following for VERIFYPEER (and
> VERIFYHOST), both of which seem to be things you want to enable.
To enable the certs verification, either the bug #6661895 needs to be
fixed first, or the certs are shipped in WebKit or libcurl. I'm
personally not a fan for the second choice.
Regards,
-Alfred
> Hugh.
>
> _____________________________________________________________________________
>
>
> CURLOPT_SSL_VERIFYPEER
>
> Pass a long as parameter.
>
> This option determines whether curl verifies the authenticity of the
> peer's certificate. A value of 1 means curl verifies; zero means it
> doesn't. The default is nonzero, but before 7.10, it was zero.
>
> When negotiating an SSL connection, the server sends a certificate
> indicating its identity. Curl verifies whether the certificate is
> authentic, i.e. that you can trust that the server is who the
> certificate says it is. This trust is based on a chain of digital
> signatures, rooted in certification authority (CA) certificates you
> supply. As of 7.10, curl installs a default bundle of CA certificates
> and you can specify alternate certificates with the CURLOPT_CAINFO
> option or the CURLOPT_CAPATH option.
>
> When CURLOPT_SSL_VERIFYPEER is nonzero, and the verification fails to
> prove that the certificate is authentic, the connection fails. When
> the option is zero, the connection succeeds regardless.
>
> Authenticating the certificate is not by itself very useful. You
> typically want to ensure that the server, as authentically identified
> by its certificate, is the server you mean to be talking to. Use
> CURLOPT_SSL_VERIFYHOST to control that.
>
> CURLOPT_SSL_VERIFYHOST
>
> Pass a long as parameter.
>
> This option determines whether libcurl verifies that the server cert
> is for the server it is known as.
>
> When negotiating a SSL connection, the server sends a certificate
> indicating its identity.
>
> When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that
> the server is the server to which you meant to connect, or the
> connection fails.
>
> Curl considers the server the intended one when the Common Name field
> or a Subject Alternate Name field in the certificate matches the host
> name in the URL to which you told Curl to connect.
>
> When the value is 1, the certificate must contain a Common Name field,
> but it doesn't matter what name it says. (This is not ordinarily a
> useful setting).
>
> When the value is 0, the connection succeeds regardless of the names
> in the certificate.
>
> The default, since 7.10, is 2.
>
> This option controls checking the server's claimed identity. The
> server could be lying. To control lying, see CURLOPT_SSL_VERIFYPEER.
