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 > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org _________________________________________________________________ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1
