Hi Darren/Mark, Before I started the arc case, I sent a query with regards to this HTTPS support issue to the WebKit community. Dan Winship, the libsoup developer, gave me some insight into the problem: http://lists.macosforge.org/pipermail/webkit-dev/2009-June/008566.html.
Roughly there are two points from the reply: - An x509 file containing the certificate can be passed to SoupSession for verification. In this way, only the "correctly-named non-expired certificates signed by one of those CAs" will be accepted, all others will be rejected. From the libsoup client howto: http://library.gnome.org/devel/libsoup/stable/libsoup-client-howto.html, I think it's possible to make WebKit accept user-specified certificate with some coding. On the other hand, we could point the SOUP_SESSION_SSL_CA_FILE to the system bundled certificates if that's available. - "There is not currently any way to let the application decide on a case-by-case basis whether or not to accept a certificate." With Firefox, users can decide whether they want to accept a certificate. Users won't be able to do this with WebKit. As for the current status of the WebKit HTTPS support, I've verified with the WebKit test Program, named GtkLauncher. It's a very simple browser GUI. GtkLauncher can accept all the https request by default. If I patch the code as Dan suggested, it denies all the https website instead. >From the source code: http://svn.webkit.org/repository/webkit/trunk/WebCore/platform/network/soup/ResourceHandleSoup.cpp, you can notice that WebKit uses soup_session_async_new to create the SoupSession without setting any additional options. That's the reason why WebKit ignores all certificate validation and accepts all certificates by default I think. On 08/ 6/09 10:47 PM, Darren J Moffat wrote: > Mark Martin wrote: > >> I don't think the only issue is the lack of a handy, well known cert >> repository; the fact that the underlying implementation doesn't >> validate properly would probably surprise folks. >> > That really depends on what you mean by "validate properly", sure there > are standards that define how this is done but one persons proper > validation is also over the top for other cases and highly in sufficient > for others. > > >> The choices that I saw were: >> a) Deliver with HTTPS disabled by default. Principle of least >> astonishment. >> > By disabled by default is it available to consumers of WebKit easily or > do they have to rebuild it ? > A possible workaround is that we could patch the code to enable environment variable checking so that consumers of WebKit can switch on the https support easily (no need to rebuild). By doing this, the HTTPS support of WebKit 1.1.x will be consistent with the last WebKit arc case. Just need to note that WebKit will still ignore the certificate verification in this case. >> b) Deliver with (incomplete and ostensibly unsafe) HTTPS enabled by >> default. >> >> If you're insisting on B, how do you advise managing the gap? Log a >> bug? Document a warning? Assume developers will be diligent or just know? >> > To be able to answer that I need to understand if this gap exists on > other platforms delivering WebKit or is it somehow unique to OpenSolaris ? There is an old version of WebKit in Ubuntu repository: http://packages.ubunut.com/jaunty/libwebkit-1.0-1. It still uses libcURL from the dependency list. With package "ca-certificates" installed on Ubuntu by default, WebKit can accept the authorized certificates. However, it won't accept the server certificates that can't be match with the system bundled ones. That's to say, some of the https website will fail to load. Since WebKit 1.1.x is targeted for GNOME 2.28, I think it'll be probably available for the next Ubuntu release. We'll know how Ubuntu handles HTTPS support with libsoup then. Personally I'd propose to disable the HTTPS support for now and push the integration of certificates to OpenSolaris. When it's ready, we can enable the HTTPS support. Thanks, -Alfred
