Description of problem: When attempting to access Cockpit on another machine using the Google Chrome 46 web browser, I am presented with the login screen, but only a blank white screen after logging in. Version-Release number of selected component (if applicable): cockpit-0.79-1.fc23 How reproducible: Every time for remote servers. When accessing on localhost, the problem does not present. Steps to Reproduce: 1. Install Fedora 23 Server with default settings and boot it. 2. Connect to the URL shown on the non-graphical login prompt Actual results: After logging in, presented only with a blank screen. Expected results: Cockpit should be functional. Additional info: Logs from the server: Oct 19 11:15:14 ipaserver cockpit-ws[1324]: couldn't read from connection: Peer failed to perform TLS handshake Oct 19 11:15:14 ipaserver cockpit-ws[1324]: couldn't read from connection: Error performing TLS handshake: A connection with inappropriate fallback was attempted. Oct 19 11:15:14 ipaserver cockpit-ws[1324]: couldn't read from connection: Error performing TLS handshake: A connection with inappropriate fallback was attempted. Oct 19 11:15:14 ipaserver cockpit-ws[1324]: couldn't read from connection: Error performing TLS handshake: An unknown public key algorithm was encountered. The Chrome console: Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/shell/bundle.js Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/shell/images/server-small.png Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/shell/index.js Failed to load resource: the server responded with a status of 404 (Not Found) base1/patterns.min.js:2 Uncaught Error: Script error for: shell/index http://requirejs.org/docs/errors.html#scripterror https://192.168.124.79:9090/cockpit/static/branding.css Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/base1/bundle.js Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/shell/shell.js Failed to load resource: net::ERR_CONNECTION_CLOSED https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/dashboard/bundle.js Failed to load resource: net::ERR_CONNECTION_CLOSED shell/machines.min.js:2 Uncaught ReferenceError: define is not defined shell/machines.min.js:2 Uncaught ReferenceError: define is not defined https://192.168.124.79:9090/cockpit/$68a59d941d066dbdfaacb6dc2067946baff439bc/domain/bundle.js Failed to load resource: net::ERR_CONNECTION_CLOSED index.html:31 Uncaught ReferenceError: require is not defined system/renderer.min.js:2 Uncaught ReferenceError: define is not defined index.html:1 Uncaught ReferenceError: require is not defined
I forgot to note: Mozilla Firefox does not encounter this issue. I also just tested Epiphany, which also fails to display Cockpit, but with a different experience. (I will attach a screencast).
(In reply to Stephen Gallagher from comment #1) > I also just tested Epiphany, which also fails to display Cockpit, but with a > different experience. (I will attach a screencast). Ignore this; Epiphany breakage is unrelated.
Proposed as a Blocker for 23-final by Fedora user sgallagh using the blocker tracking app because: From the Beta criteria: "It must be possible to log in to the default Cockpit instance and use it to: View the system's logs View the system's running services Enrol the system to a FreeIPA or Active Directory domain" This may be a conditional violation. Firefox as shipped in Fedora works properly.
I can reproduce this with gnutls-serv and Google Chrome. I rebuilt gnutls via 'fedpkg local' on the f23 branch to make sure I had the latest. Chrome is: Version 46.0.2490.71 (64-bit) I followed these instructions (although skipped generating the client certificate). Started at 'gnutls-serv Examples'. I used 'localhost' as my DNS name. http://gnutls.org/manual/html_node/gnutls_002dserv-Invocation.html Which resulted in the following output. The page loads once fine ... and then F5 refresh fails with 'SSL connection error ERR_SSL_PROTOCOL_ERROR' displayed in Chrome. $ gnutls-serv --http --x509cafile x509-ca.pem --x509keyfile x509-server-key.pem --x509certfile x509-server.pem Set static Diffie-Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). HTTP Server listening on IPv4 0.0.0.0 port 5556...done HTTP Server listening on IPv6 :: port 5556...done * Accepted connection from IPv4 127.0.0.1 port 45876 on Mon Oct 19 18:01:08 2015 Error in handshake Error: The TLS connection was non-properly terminated. * Accepted connection from IPv4 127.0.0.1 port 45878 on Mon Oct 19 18:01:08 2015 Error in handshake Error: The TLS connection was non-properly terminated. * Accepted connection from IPv4 127.0.0.1 port 45880 on Mon Oct 19 18:01:08 2015 - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-GCM) - Session ID: 1D:58:FA:C3:41:70:6D:6B:B3:37:0D:CD:E3:83:5C:2F:F1:E3:00:D4:15:C5:29:65:C0:34:F7:2D:77:93:34:9D - Given server name[1]: localhost No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA512 - Cipher: AES-128-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Channel binding 'tls-unique': d6d53826de4d7c305b9d6a86 Error while receiving data Error: The TLS connection was non-properly terminated. * Accepted connection from IPv4 127.0.0.1 port 45882 on Mon Oct 19 18:01:08 2015 - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-GCM) - Session ID: B8:81:99:CD:2B:F6:FF:57:E3:30:69:2F:3E:BA:57:1F:23:E4:74:55:8F:EE:02:54:A7:F7:43:21:91:A1:7B:4F - Given server name[1]: localhost No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA512 - Cipher: AES-128-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Channel binding 'tls-unique': 3250c70f6113f31aa1de7a48 * Accepted connection from IPv4 127.0.0.1 port 45884 on Mon Oct 19 18:01:08 2015 * Received alert '40': Handshake failed. Error in handshake Error: A TLS fatal alert has been received. * Accepted connection from IPv4 127.0.0.1 port 45886 on Mon Oct 19 18:01:08 2015 Error in handshake Error: A connection with inappropriate fallback was attempted. * Accepted connection from IPv4 127.0.0.1 port 45888 on Mon Oct 19 18:01:09 2015 * Received alert '40': Handshake failed. Error in handshake Error: A TLS fatal alert has been received. * Accepted connection from IPv4 127.0.0.1 port 45890 on Mon Oct 19 18:01:09 2015 * Received alert '40': Handshake failed. Error in handshake Error: A TLS fatal alert has been received. * Accepted connection from IPv4 127.0.0.1 port 45892 on Mon Oct 19 18:01:09 2015 Error in handshake Error: A connection with inappropriate fallback was attempted.
Created attachment 1084454 [details] Packet capture of failed handshake This is a packet capture. First comes the successful handshake, and then the failed one follows. The same events occur as in the log above. However this is a different invocation of gnutls-serv so some ephemeral data may differ.
(In reply to Stef Walter from comment #5) > Created attachment 1084454 [details] > Packet capture of failed handshake The issue seems to be related to session resumption and extended master secret. The server does not advertise support for extended master secret in abbreviated handshakes thus the client (Chrome) does abort the connection. The the fallback mechanism kicks in and the client retries the connection with lower protocol version, but with TLS_FALLBACK_SCSV, that in turn is aborted by server, as the server support TLSv1.2. This is incorrect behaviour on GnuTLS part. Per RFC 7627: If the original session uses an extended master secret but the ClientHello or ServerHello in the abbreviated handshake does not include the extension, it MAY be safe to continue the abbreviated handshake since it is protected by the extended master secret of the original session. This scenario may occur, for example, when a server that implements this extension establishes a session but the session is subsequently resumed at a different server that does not support the extension. Since such situations are unusual and likely to be the result of transient or inadvertent misconfigurations, this document recommends that the client and server MUST abort such handshakes.
upstream bug: https://gitlab.com/gnutls/gnutls/issues/45
Discussed at 2015-10-19 blocker review meeting: https://meetbot.fedoraproject.org/fedora-blocker-review/2015-10-19/f23-blocker-review.2015-10-19-16.00.html . We accepted this as at least a freeze exception issue; we were not sure about blocker status, and wanted to wait at least for clear information on whether it should be fixed GnuTLS/Cockpit side or Chrome side.
Hi, the issue as described by Hubert is in gnutls' handling of extended master secret, so the fix will be there. Could you verify that this scratch build addresses the issue? http://koji.fedoraproject.org/koji/taskinfo?taskID=11511588
This build fixes the symptom of Cockpit not loading: http://koji.fedoraproject.org/koji/taskinfo?taskID=11511588
Nikos: could you please do a real build and update? we need that to include in the release. Thanks!
Actually, a whole version bump is not the best idea during freeze. I will try and do a 3.4.5-2 with the fix backported.
gnutls-3.4.5-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b0188d12d9
(In reply to awilliam from comment #12) > Actually, a whole version bump is not the best idea during freeze. I will > try and do a 3.4.5-2 with the fix backported. Please allow the maintainer of the package to judge that.
Actually, no, it's not up to your judgement; it's a part of the freeze policy. Only fixes for FE and blocker bugs are allowed through the milestone freezes; the update must be as specifically targeted to the FE/blocker bug as possible. This bug has a freeze exception (and may potentially be a release blocker), none of the other changes from gnutls 3.4.6 addresses an FE or blocker bug.
(having said that I did the update because I thought we had a chance to build RC1 while it was night time for you, as it turned out we're stuck on another blocker so it wasn't really necessary - if I'd known that I would've waited).
Discussed at 2015-10-22 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2015-10-22/f23-final-go_no_go-meeting.2015-10-22-16.00.log.txt . Rejected as a blocker on the basis that, so far as I can tell, 'it works on Firefox'. Abusing my power as secretary to state that I think this was a wrong call, and I think the fact that Chrome isn't shipped in Fedora is not relevant at all. The criterion says Cockpit must work, and this bug means it *doesn't* work for anyone using the world's most popular browser. Still, the fix was pulled as an FE in RC2, so for practical purposes the decision wasn't terribly important.
gnutls-3.4.5-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update gnutls' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b0188d12d9