[Webkit-unassigned] [Bug 162910] [SOUP] Move global TLS errors handling from ResourceHandle to SoupNetworkSession

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 5 00:58:53 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=162910

--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #6)
> Comment on attachment 290695 [details]
> Updated patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=290695&action=review
> 
> Yep.  Moves the code.  Great.  r=me

Thanks!

> > Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:80
> > +        SHA1 sha1;
> 
> You should probably migrate away from SHA1, it being theoretically not
> cryptographically secure and all...

I'm not security expert, but I don't see the security problem here yet, I can understand it's not safe to use SHA1 for signing something or hashing private info like a password, but here we just want to get a checksum to make comparisons.

> > Source/WebKit2/NetworkProcess/soup/NetworkProcessSoup.cpp:86
> > -    ResourceHandle::setIgnoreSSLErrors(ignoreTLSErrors);
> > +    SoupNetworkSession::setShouldIgnoreTLSErrors(ignoreTLSErrors);
> 
> It seems like we should work towards removing this, too.  Very bad things
> can happen when we ignore TLS errors.

This is disabled by default of course, and only enabled when explicitly set by API users. See GTK+ API for example:
 https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html#WebKitTLSErrorsPolicy

The default is fail, of course, and web browser applications should never change that setting.

> > Source/WebKit2/NetworkProcess/soup/NetworkProcessSoup.cpp:91
> > -    ResourceHandle::setClientCertificate(host, certificateInfo.certificate());
> > +    SoupNetworkSession::allowSpecificHTTPSCertificateForHost(certificateInfo, host);
> 
> We are also moving away from allowing specific TLS certificates.  I'm going
> to do this on Cocoa by using SecTrustEvaluateAsync with a few additional
> checks in the NetworkProcess after receiving the server trust evaluation
> challenge.  This will avoid IPC and allow us to quickly and asynchronously
> connect to most HTTPS servers that use modern TLS and valid certificates. 
> In the case where it fails such as on badssl.com we will send IPC to the
> UIProcess which has the option of responding and saying to trust the server
> even though it's probably unsafe.

I'll see if we can do something similar.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161005/c16b8335/attachment.html>


More information about the webkit-unassigned mailing list