[Webkit-unassigned] [Bug 158345] [websocket] does not send client certificate

[bugzilla-daemon at webkit.org]

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

--- Comment #6 from Tor Arne Vestbø (not active) <vestbo at webkit.org> ---
Poking a bit a bit at this, it looks like normal loads are fed through WKNetworkSessionDelegate in NetworkSessionCocoa.mm in the Network process, where [WKNetworkSessionDelegate URLSession:task:didReceiveChallenge:completionHandler:] gets a callback with NSURLAuthenticationMethodClientCertificate, which is passed on to the UIProcess via NetworkLoad::didReceiveChallenge() and NetworkProcess::singleton().authenticationManager().didReceiveAuthenticationChallenge(), coming back from the UIProcess via AuthenticationManager::useCredentialForChallenge(), finally ending up calling the completion handler of the original callback.

WebSocket connections are also handled in the Network process, via SocketStreamHandle and SocketStreamHandleImpl in SocketStreamHandleImplCFNet.cpp, which sets up the connection in SocketStreamHandleImpl::createStreams(). There is some logic there for credentials via SocketStreamHandleImpl::getStoredCONNECTProxyCredentials, but nothing for client certificates. Presumably the fix here is to set the kCFStreamPropertySSLSettings property on the CFWriteStreamRef to a dict that includes the cert for the the kCFStreamSSLCertificates key.

The question is how to plumb a previously accepted cert on the UI side to the cert on the network process side. The normal load works via a callback, while CFStream seems to require the property to be set up front. There doesn't seem to be any way to peek into the cert negotiation and only ask for the cert and set the property at that point.

Alex, any thoughts?

One thing to note, is that the original bugreport described the reproducer as just connecting via new WebSocket('wss://localhost/test');, but this is not supported in Chrome either. You need to do a normal page load first, and then do websocket requests after accepting the cert in the UI. Running the reproducer with s_server -HTTP should make that easy to test by first loading a file on disk and then doing the JS bit within the loaded page.

For reference, I couldn't get Chrome or Safari to accept the self-signed server cert without a SAN. Here's what I used instead:

openssl req -x509 -nodes -new -out server.crt -keyout server.key -subj /CN=localhost -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf && printf '[SAN]\nsubjectAltName=DNS:localhost,IP:127.0.0.1') -sha256 -days 3650

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