Bug 157884 – [WebSockets] No infrastructure for testing secure web sockets (wss)

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Brent Fulgham]

It appears that the existing socket server configuration has SSL support turned off. We need to activate SSL support and update the test machines with appropriate settings to enable these test.

Proper WSS tests should then be added to the regression tests.

[Brent Fulgham]

It looks like there might be some 'wss' test features in 'imported/w3c', but they don't seem to be used on WebKit. We should review the w3c suite and see if there are any tests we can add.

[Daniel Bates]

Created attachment 279418 [details]
Work-in-progress patch

Work-in-progress patch.

Adds support to webkitpy to start and stop a secure Web Socket server running on port 9323 using the certificate, private-key from file LayoutTests/http/conf/webkit-httpd.pem and adds a new test, LayoutTests/http/tests/websocket/tests/hybi/simple-wss.html, to test making a secure Web Socket connection. Also teaches run-webkit-httpd to start and stop the Web Socket servers.

We need to teach the Web Socket code to allow self-signed certificates/allow certificates with an invalid certificate chain when run in a testing environment similar to what we do to make HTTPS work in our testing environment. Otherwise, the test LayoutTests/http/tests/websocket/tests/hybi/simple-wss.html will fail with Web Inspector console message "WebSocket network error: OSStatus Error -9807: Invalid certificate chain". We also need to ensure that logic to extract the certificate and private key file from file LayoutTests/http/conf/webkit-httpd.pem works on Windows.

Until we teach the Web Socket code to allow self-signed certificates/allow certificates with an invalid certificate chain when run in a testing environment the SSL certificate will need to be trusted in order for the test LayoutTests/http/tests/websocket/tests/hybi/simple-wss.html to pass. On OS X, you can trust the WebKit Layout Tests certificate by performing the following:

1. Apply the patch.
2. Run script run-webkit-httpd.
3. In Safari, navigate to https://127.0.0.1:9323. When Safari presents the sheet "Safari can't verify the identity of the website “127.0.0.1”, check the checkbox Always trust “WebKit LayoutTests” when connecting to “127.0.0.1” and click the Continue button.

The certificate WebKit LayoutTests is now trusted and running test LayoutTests/http/tests/websocket/tests/hybi/simple-wss.html will pass:

Tools/Scripts/run-webkit-tests LayoutTests/http/tests/websocket/tests/hybi/simple-wss.html

To untrust WebKit LayoutTests, perform the following:

1. Open Keychain Access.
2. Ensure the keychain is unlocked. (If it is locked, then click the lock icon in the top left corner of the window and authenticate to unlock the keychain).
3. Click Certificates in the Category pane on the bottom left-side of the window to show the installed certificates.
4. Click WebKit LayoutTests in the list of Certificates to highlight it.
5. Press the delete key on the keyboard to delete it.

[Brent Fulgham]

<rdar://problem/26477197>

[Brent Fulgham]

Created attachment 279812 [details]
Patch

[Andy Estes]

Comment on attachment 279812 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=279812&action=review

> Source/WebCore/page/Settings.cpp:104
> +bool Settings::gAllowsAnySSLCertificate = false;

It's not clear that "allow any certificate" and "do not validate the certificate chain" are the same thing. Perhaps there are some certificates that would be rejected even when not validating the certificate chain? Anyway, I'd prefer this setting to be named more closely to the CFNetwork flag.

> Source/WebCore/testing/js/WebCoreTestSupport.cpp:3
> + * Copyright (C) 2016 Apple Inc.  All rights reserved.

Only one space after the period, please.

[Brent Fulgham]

Comment on attachment 279812 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=279812&action=review

>> Source/WebCore/page/Settings.cpp:104
>> +bool Settings::gAllowsAnySSLCertificate = false;
> 
> It's not clear that "allow any certificate" and "do not validate the certificate chain" are the same thing. Perhaps there are some certificates that would be rejected even when not validating the certificate chain? Anyway, I'd prefer this setting to be named more closely to the CFNetwork flag.

I chose the naming to match the existing NSURLRequest allowsAnyHTTPSCertificateForHost. When I spoke to the CFNetwork people, they told me that setting kCFStreamSSLValidatesCertificateChain to kCFBooleanFalse was the equivalent operation at the CFStream level.

>> Source/WebCore/testing/js/WebCoreTestSupport.cpp:3
>> + * Copyright (C) 2016 Apple Inc.  All rights reserved.
> 
> Only one space after the period, please.

Done!

[Andy Estes]

(In reply to comment #6)
> Comment on attachment 279812 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=279812&action=review
> 
> >> Source/WebCore/page/Settings.cpp:104
> >> +bool Settings::gAllowsAnySSLCertificate = false;
> > 
> > It's not clear that "allow any certificate" and "do not validate the certificate chain" are the same thing. Perhaps there are some certificates that would be rejected even when not validating the certificate chain? Anyway, I'd prefer this setting to be named more closely to the CFNetwork flag.
> 
> I chose the naming to match the existing NSURLRequest
> allowsAnyHTTPSCertificateForHost. When I spoke to the CFNetwork people, they
> told me that setting kCFStreamSSLValidatesCertificateChain to
> kCFBooleanFalse was the equivalent operation at the CFStream level.

Fair enough, thanks for the explanation. Matching the NSURLRequest SPI name is reasonable.

> 
> >> Source/WebCore/testing/js/WebCoreTestSupport.cpp:3
> >> + * Copyright (C) 2016 Apple Inc.  All rights reserved.
> > 
> > Only one space after the period, please.
> 
> Done!

[Brent Fulgham]

Committed r201404: <http://trac.webkit.org/changeset/201404>