Bug 41419

Summary: We should log the reason when a secure wss WebSocket connection could not be established
Product: WebKit Reporter: Martyn Loughran <mail>
Component: Web InspectorAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ap, bfulgham, fishd, graouts, inspector-bugzilla-changes, joenotcharles, webkit-bug-importer, wilander
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 40945    

Description Martyn Loughran 2010-06-30 10:07:52 PDT
I have not been able to connect to a secure wss:// websocket servers using either Safari 5 or the WebKit nightly.

I have tried the following server implementations: em-websocket (http://github.com/igrigorik/em-websocket) and pywebsocket (http://code.google.com/p/pywebsocket/). For both servers I used a self signed certificate, which I also added as a trusted certificate to my keychain (which made no difference). Both of these server implementations work with Chrome (tested with version 6.0.447.0 dev).

It appears that there is an error establishing an SSL connection. The stacktrace from pywebsocket (instructions to replicate below) looks like this.

    [2010-06-30 17:24:10,655] [ERROR] root: Exception in processing request from: ('127.0.0.1', 59399)
    Traceback (most recent call last):
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/SocketServer.py", line 558, in process_request_thread
        self.finish_request(request, client_address)
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/SocketServer.py", line 320, in finish_request
        self.RequestHandlerClass(request, client_address, self)
      File "standalone.py", line 237, in __init__
        self, *args, **keywords)
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/SocketServer.py", line 615, in __init__
        self.handle()
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/BaseHTTPServer.py", line 329, in handle
        self.handle_one_request()
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/BaseHTTPServer.py", line 312, in handle_one_request
        self.raw_requestline = self.rfile.readline()
      File "/Library/Python/2.6/site-packages/mod_pywebsocket/memorizingfile.py", line 71, in readline
        line = self._file.readline()
      File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.py", line 395, in readline
        data = recv(1)
    Error: [('SSL routines', 'SSL23_READ', 'ssl handshake failure')]

I also tried using stunnel in front of a patched em-websocket server (operating in non ssl mode, but returning the correct wss handshake). This worked in Chrome, but for the WebKit case the connection was terminated in stunnel with the following debug log:

    2010.06.30 17:20:47 LOG7[31326:140735074479136]: wss accepted FD=11 from 127.0.0.1:59205
    2010.06.30 17:20:47 LOG7[31326:4297367552]: wss started
    2010.06.30 17:20:47 LOG7[31326:4297367552]: FD 11 in non-blocking mode
    2010.06.30 17:20:47 LOG7[31326:4297367552]: Waiting for a libwrap process
    2010.06.30 17:20:47 LOG7[31326:4297367552]: Acquired libwrap process #0
    2010.06.30 17:20:47 LOG7[31326:4297367552]: Releasing libwrap process #0
    2010.06.30 17:20:47 LOG7[31326:4297367552]: Released libwrap process #0
    2010.06.30 17:20:47 LOG7[31326:4297367552]: wss permitted by libwrap from 127.0.0.1:59205
    2010.06.30 17:20:47 LOG5[31326:4297367552]: wss accepted connection from 127.0.0.1:59205
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): before/accept initialization
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): SSLv3 read client hello A
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): SSLv3 write server hello A
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): SSLv3 write certificate A
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): SSLv3 write server done A
    2010.06.30 17:20:47 LOG7[31326:4297367552]: SSL state (accept): SSLv3 flush data
    2010.06.30 17:20:47 LOG3[31326:4297367552]: SSL_accept: Peer suddenly disconnected
    2010.06.30 17:20:47 LOG5[31326:4297367552]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
    2010.06.30 17:20:47 LOG7[31326:4297367552]: wss finished (0 left)

Nothing is logged in Safari or to Console.app, so I'm slightly at a loss how to debug further.

Replicating with pywebsocket:

* Download from http://code.google.com/p/pywebsocket/
* Install (see README)
* Run standalone server
** cd `src/mod_pywebsocket`
** `sudo python standalone.py -t -p 443 -k keyfile -c certfile --allow-draft75`
* Connect from WebKit
Comment 1 Alexey Proskuryakov 2010-07-01 09:21:04 PDT
What happens if you try to connect to the same host via HTTP (i.e., by entering an http:// address in address bar)? Is there an SSL certificate error displayed?

WebSocket spec says:

   4.   If /secure/ is true, perform a TLS handshake over the
        connection.  If this fails (e.g. the server's certificate could
        not be verified), then fail the WebSocket connection and abort
        these steps.
Comment 2 Alexey Proskuryakov 2010-07-01 09:22:06 PDT
> entering an http:// address

I meant https://, sorry.
Comment 3 Martyn Loughran 2010-07-05 08:49:57 PDT
Alexey,

You're absolutely correct. The self signed certificate was not trusted by Safari and after changing the setting to always trust this certificate the WebSocket connection worked. So thanks!

I wonder though whether it would be possible to make this more user friendly? Bringing up the same certificate warning message that Safari uses for https would seem to be ideal, but if that's not possible at least logging the failure reason somewhere would be really useful.
Comment 4 Alexey Proskuryakov 2010-07-05 12:27:13 PDT
Logging is absolutely what we should do. I'm not convinced that a warning sheet is a good idea - providing an easy way to bypass security equals to having no security at all, and we can avoid that for WebSocket, that would be good.

We might eventually have to show the warning sheet due to pressure from other browsers (I'm told Chrome does that).
Comment 5 Radar WebKit Bug Importer 2014-08-03 19:28:55 PDT
<rdar://problem/17898486>