_ssl.c:510: EOF occurred in violation of protocol on Safari Version 8.0.6 (10600.6.3) and IOS

[rogaha]

I see this message: _ssl.c:510: EOF occurred in violation of protocol

On Chrome and Firefox it works correctly.

[rogaha]

It doesn't work for Chrome and Safari on IOS as well.

[EddoH]

Just want to say I have the exact same issue. It makes noVNC currently useless in HTTPS environments when you want to support all major platforms. HTTP is no option anymore nowadays. Didn't have time to have a thorough look into it yet. Hope to report back soon.

If anyone has some starting pointers, would appreciate it.

[beeelze]

I don't think it's an issue related to just noVNC. I have the same problem with websockify, where any browser (Safari, Firefox and Chrome) reports a different error message when running the service on a Linux server.

-- Safari: public IP address: _ssl.c:510: EOF occurred in violation of protocol; -- FireFox: handler exception: [Errno 1] _ssl.c:1429: error:14094412: routines:SSL3_READ_BYTES:sslv3 alert bad certificate; -- Chrome: handler exception: WSRequestHandler instance has no attribute 'last_code'.

And unfortunately, when a page is loaded through HTTPS, browsers don't allow security to be "downgraded". This means that Web Sockets over SSL / TLS have to be used with HTTPS while regular Web Sockets can be used with paged loaded through HTTP.

[kanaka]

wss (ss/tls) with websockify does work given the right setup.

I think sometimes those sort of errors happen when the browser doesn't trust the server's certificate (which is the typical case if you are using a self-signed cert with webosckify. Unfortunately, websocket connections don't trigger a browser popup to confirm the cert like normal browsing to an https site does. You can force the browser to accept the cert by browsing directly to the websocket port using https://, and then you should be able to connect (at least for that browser session). More permanent resolution would be to get a real signed cert (should soon be much easier/cheaper once letsencrypt.com reaches wide availability).

I think there are also some other situations where those errors can happen too. If anybody experiencing them is certain they aren't running into a cert signing issue, we would definitely be interested in getting more details (for example, trying curl/wget/openssl directly to the websocket address and seeing what happens) so that we can track it down and squash them.

[EddoH]

On my setup I have a real signed certificaten, and the error only occurs when using Safari. Haven't had the time to look at in detail yet, but it certainly does not happen only when using self-signed certificates.

[kanaka]

@EddoH okay, that's good information. It might be interesting if you could test a new version of python (3.X) if you are able (assuming you aren't already).

[beeelze]

@kanaka My setup also has a real signed certificate, but my situation slightly differs from EddoH's because mine occurs on all browsers. Going to https://server IP address:port gives me a response that the certificate is not valid and that I have to add it as an exception. Next the browser returns:

Error response

Error code 405.

Message: Method Not Allowed.

Error code explanation: 405 = Specified method is invalid for this resource..

~$ python -V Python 2.7.6 ~$ python3 -V Python 3.4.3

python3 websockify.py 2023 --wrap-mode=respawn 10.91.244.201:2034 --ssl-only --cert=real.crt shows these errors:

Safari: EOF occurred in violation of protocol (_ssl.c:600) FireFox: handler exception: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1769)

Chrome doesn't even do anything now.

[beeelze]

Analyzing a tcpdump ( sudo tcpdump -i eth0 -s 65535 -w file ) shows the following:

Somehow the reset flag of the TCP header is set.

[kanaka]

@beeelze can you expand on what you mean that Chrome doesn't do anything? Does it try and connect at all? You indicated that the certificate is real, but is it for a different domain/IP? The browser shouldn't complain when you browse there directly if the cert is real and for that location. I suspect in your case there is still a certificate issue. I would work on getting your certificate configuration correct (no complaint/warning when browsing there directly) first. It's possible that certain cert issues are bypass by accepting the cert directly (self-signed), and some may not be (wrong domain/IP). It would be good to be able eliminate normal cert issues from actual websockify issues.

Thanks for the dump. However, I can't tell from that what direction the RESET is going. Also, how many packets were transferred and in which direction prior to the RESET.

[beeelze]

When running websockify the normal way i.e. ./run 2023 --wrap-mode=respawn 10.10.10.0:2034 --ssl-only --cert=real.pem I get a different error on all 3 browsers. But when I run the command with python3 i.e. python3 websockify.py 2023 --wrap-mode=respawn 10.10.10.0:2034 --ssl-only --cert=real.pem the only browser that doesn't report an error or anything at all is Chrome. I thought it was worth mentioning the difference between the 2 python versions.

Just to confirm my certificate settings are correct:

The file real.pem consists of -----BEGIN PRIVATE KEY----- // key -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- // cert -----END CERTIFICATE----- which are set in the /etc/apache2/sites-enabled/mysite file as the SSLCertificateKeyFile and SSLCertificateFile parameters of apache2. This is the website with the certificate: https://teamworks.fusix.nl. You can see that it is valid. I could try doing something with a self-signed certificate to eliminate normal cert issues, that's a good one. UPDATE: no difference, there must be something else.

Some elaboration of the tcpdump. A TCP connection is made from my router 37.139.139.29 to the server where websockify is running 37.139.139.35 (port 2023). The dump i have shows that these errors in wireshark usually come with 2 packets after each other. I haven't really filtered on anything as you can see from the command I issued on the server.

Oh, one last thing. The 'method not allowed' error is my fault. I did https://mysite:2023. That doesn't work of course because the method is web socket and not HTTPS.

[kanaka]

@beeelze when you specify the host in noVNC are you using teamworks.fusix.nl (i.e. the name that matches the certificate) or are you using something else (IP or other alias).

And for each browser (after restarting the browser from scratch), what is the result of connecting to https://mysite:2023. Do you still get a certificate warning before you get the "method not allowed"? If you are getting a certificate warning then the problem is with your certificate configuration or the way host resolution is working on your network (resolving to something that's not signed in the certificate).

You can also run websockify with the embedded web server enabled. You should be able to get to pages in the directory it is serving without certificate warnings or errors. If that has problems, you can always try and create a small python web server with your certificate. Depending on whether that works or not, that would give guidance on where the problem is located.

[beeelze]

@kanaka I haven't really checked noVNC on SSL yet. For noVNC i use this URL:

http://hypervisor1.net:8000/vnc_auto.html?host=hypervisor1.net&port=8000

which is pointed to the hypervisor where the guests are installed. I launched noVNC with the following command:

./utils/launch.sh --vnc localhost:5901 --listen 8000

This works perfectly on just HTTP. For my project there is yet no need for this to work on HTTPS, perhaps in the future it will.

I understand this issue was openend on your noVNC project, but I thought since my websockify returns the same error as the opener of this issue mentioned I could reopen this discussion :-)

Going to https://teamworks.fusix.nl:2023 returns method not allowed on every browser. How would I run websockify with the embedded web server enabled?

Using self.pem on websockify and the real signed certificate on my browser also returns "EOF occurred in violation of protocol (_ssl.c:600)". It's like it's never checking the certificates anywhere. What am I missing?

[beeelze]

I just checked the intermediate certificates and added them to my Apache configuration:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/teamworks.fusix.nl.crt
SSLCertificateKeyFile /etc/ssl/private/teamworks.fusix.nl.key
SSLCertificateChainFile /etc/ssl/ca-certificates.crt 

teamworks.fusix.nl.crt = server certificate; teamworks.fusix.nl.key = private key; ca-certificates = server certificate + 2 intermediate CA certificates;

Even SSL Labs reports no Chain Issues and says all paths are correct: https://www.ssllabs.com/ssltest/analyze.html?d=teamworks.fusix.nl&hideResults=on

The command I'm running:

python3 websockify.py 2023 --wrap-mode=respawn 10.91.244.201:2034 --ssl-only --cert=/etc/ssl/ca-certificates.crt --key=/etc/ssl/private/teamworks.fusix.nl.key

But still, same errors.. In wireshark I constantly see RST, ACK's suggesting that the SSL connection is shutdown immediately when it wants to start. I really don't get it.

[beeelze]

I just got it working!! I made a huge mistake creating a secure web socket connection.. The certificate I have is not given for a specific IP address but for my domain *.fusix.nl. Once I did wss://teamworks.fusix.nl:2023 I instantly got a connection and I could happily use the telnet client.

This issue can be Closed for me. I hope I have helped or will help others in the future with this issue.

[rogaha]

I don't think I did the same mistake and I'm still getting this error.

[DirectXMan12]

@rogaha we're going to need some more information about your environment, and how you're running noVNC (include versions of websockify, noVNC, and Python).