WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
157884
[WebSockets] No infrastructure for testing secure web sockets (wss)
https://bugs.webkit.org/show_bug.cgi?id=157884
Summary
[WebSockets] No infrastructure for testing secure web sockets (wss)
Brent Fulgham
Reported
2016-05-18 21:42:19 PDT
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.
Attachments
Work-in-progress patch
(9.34 KB, patch)
2016-05-19 13:02 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch
(26.66 KB, patch)
2016-05-25 14:27 PDT
,
Brent Fulgham
aestes
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Brent Fulgham
Comment 1
2016-05-18 21:45:36 PDT
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
Comment 2
2016-05-19 13:02:54 PDT
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
Comment 3
2016-05-25 13:47:21 PDT
<
rdar://problem/26477197
>
Brent Fulgham
Comment 4
2016-05-25 14:27:00 PDT
Created
attachment 279812
[details]
Patch
Andy Estes
Comment 5
2016-05-25 14:34:59 PDT
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 6
2016-05-25 14:42:15 PDT
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
Comment 7
2016-05-25 14:44:13 PDT
(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
Comment 8
2016-05-25 14:56:59 PDT
Committed
r201404
: <
http://trac.webkit.org/changeset/201404
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug