<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SOUP] Move global TLS errors handling from ResourceHandle to SoupNetworkSession"
href="https://bugs.webkit.org/show_bug.cgi?id=162910#c11">Comment # 11</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SOUP] Move global TLS errors handling from ResourceHandle to SoupNetworkSession"
href="https://bugs.webkit.org/show_bug.cgi?id=162910">bug 162910</a>
from <span class="vcard"><a class="email" href="mailto:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
<pre><span class="quote">> (In reply to <a href="show_bug.cgi?id=162910#c3">comment #3</a>)
> > 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.</span >
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. <a class="bz_bug_link
bz_status_NEW "
title="NEW - [SOUP] HostTLSCertificateSet should not use SHA-1 hashes to compare certificates"
href="show_bug.cgi?id=162965">Bug #162965</a>.
(In reply to <a href="show_bug.cgi?id=162910#c6">comment #6</a>)
<span class="quote">> It seems like we should work towards removing this, too. Very bad things
> can happen when we ignore TLS errors.</span >
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.
<span class="quote">> > 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.</span >
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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>