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.).
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 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?"
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.
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.
