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

[bugzilla-daemon at webkit.org]

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

--- Comment #11 from Michael Catanzaro <mcatanzaro at igalia.com> ---
> (In reply to comment #3)
> > What's the problem of using SHA1 here? What's the security problem exactly?
> I see certificates and SHA1 and think "Somebody could theoretically create a
> collision and something unexpected could happen and that's really bad with
> certificates."  I'm not sure what the exact attack would look like, but it's
> up to you to decide whether that's important enough.

Yeah, the problem is an attacker could theoretically get a totally different certificate to be accepted. There have been very similar practical attacks published recently that work on all implementations, no need to introduce a WebKit-specific problem too. Bug #162965.

(In reply to comment #6)
> It seems like we should work towards removing this, too.  Very bad things
> can happen when we ignore TLS errors.

Unfortunately it's exposed in our API, in case applications want to shoot themselves in the foot. I'm not aware of any applications that are using it, though.

> > 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.

This is exposed in our API too, but it's only used to implement the functionality you described, so I'm not sure what the problem is?

-- 
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/002ef9a6/attachment-0001.html>