Hi Uros, Chrome browser does depend on WebKit. From its source code (788M source tarball, HUGE) and ChangeLog, I don't think Chrome uses libsoup for HTTPS support on Win and Mac. From the libsoup developer (link below), "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 libsoup. I doubt whether the way Google/Apple engineers used to solve this HTTPS support problem can apply to our case.
Thanks, -Alfred On 08/ 8/09 12:20 AM, Uros Nedic wrote: > As a pure observer of this communication I would like to > add one suggestion which, maybe, could be helpful. > > As far as I know Google's Chrome browser uses WebKit as > well as Apple's Safari on both platforms (Win and Mac). > > You could ask Google and Apple engineers how they solved > this problem. > > In Chrome when one certificate is not certified by some > 'well known' CA browser just ask user what he would like > to do. So it *is* possible to deal with this issue. > > I did not have time digging more deeply through Google's > mailing lists on code.google.com nor to see Apple's but > as far as I saw there they solved this issue. > > Hope it helps! > > Uros Nedic, MSc > Belgrade, Serbia > > P.S: Please do not disable HTTPS. I'd be big mistake, from > my perspective. > > ---------------------------------------- > >> Date: Fri, 7 Aug 2009 15:27:08 +0800 >> From: Alfred.Peng at Sun.COM >> To: Darren.Moffat at Sun.COM >> CC: desktop-discuss at opensolaris.org; storycrafter at gmail.com; LSARC-ext >> at Sun.COM >> Subject: Re: [desktop-discuss] WebKit 1.1.x [LSARC/2009/409 FastTrack >> timeout 08/04/2009] >> >> 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 >>
