I am trying to use an SSL connection with x11vnc (VNC server) and noVNC (VNC client). Whenever I try to connect, I get the error "Unsupported Security Types: 19,18" from noVNC and "SSL: ssl_helper[2957]: exit case 2 (ssl_init failed)
SSL: accept_openssl: cookie from ssl_helper[2957] FAILED. 0" from x11vnc. If I turn off SSL for x11vnc, the client is able to connect with no problem.
I do realize that x11vnc does come packaged with a java based applet viewer. However, I'm more interested in the HTML5 based noVNC.
Both x11vnc and noVNC both run on the same machine, using the commands:
x11vnc:
x11vnc -forever -shared -unixpw_cmd [cmd] -ssl [pem]
noVNC: ./utils/websockify --ssl-only --cert=[pem] --web=./ 6080 localhost:5900
Note: Both are pointing to the same pem. I use websockify instead of noVNC's launch.sh to have more options such as --ssl-only.
The encrypt option for noVNC seems to have no effect on connecting to the server (the results are the same whether it's on or off).
I am most concerned about a secure connection. As of now, it does not seem like turning on noVNC's encrypt option does much if x11vnc's SSL must be turned off (the encrypt option makes noVNC use wss:// instead of ws://). If this does create a secure connection, please let me know. Else, how can I get noVNC and x11vnc working with SSL?
First some clarifications:
noVNC and websockify are actually separate projects:
websockify is a generic proxy/bridge that allows WebSocket connections (e.g. from a browser) to connect to raw TCP socket services (e.g. a VNC server).
noVNC is the HTML5 VNC client.
If the VNC server supported WebSocket connections then websockify would not be needed. The only VNC server that currently supports direct WebSocket connections is this fork of libvncserver. websockify is included in noVNC since most VNC servers do not yet support WebSocket clients, but websockify is a separate project.
You are dealing with two different network connections each of which has separate encryption options:
noVNC (browser) to websockify - using WebSocket protocol
websockify to x11vnc (VNC server) - direct TCP socket connection
The WebSocket protocol supports unencrypted connections (ws://) and SSL/TLS encrypted connections (wss://).
The RFB protocol (Remote Frame Buffer) used in VNC has the ability to upgrade during the initialization to use an encrypted connection. There are several encryption methods supported such as TLS (security type 18), VeNCrypt (security type 19).
Now to your question:
When you pass -ssl PEM to x11vnc this enabled RFB/VNC encryption. noVNC does not support RFB/VNC encryption. Javascript is not fast enough to do encryption/decryption fast enough to be usable for noVNC. There is some discussion about adding a crypto API to Javascript which would enable noVNC to support this type of encryption.
When you enabled encryption in noVNC you are enabling WebSocket encryption (wss://). This encrypts the connection between the browser and websockify. As long as the connection between websockify and the VNC server are over a trusted network (e.g. running both on the same server) and use WebSocket encryption in noVNC then no unencrypted data will be exposed. However, if you run websockify on the same system as your browser and the VNC server is remote then the VNC traffic from you client to the server system will not be encrypted (unless noVNC gets RFB/VNC VeNCrypt encryption support in the future).
The output from websockify will indicate whether the WebSocket connection is encrypted or unencrypted.
Related
I set up my server on centos7
From client side(not localhost), I can connect and transfer files to server with unencrypted connection but can't connect with TLS
It's my vsftpd.conf:
listen=YES
listen_ipv6=NO
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
rsa_cert_file=/home/user/server/sync.crt
rsa_private_key_file=/home/user/server/sync.key
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=60000
pasv_address=1.1.1.1
and filezilla's errorcode:
Connection attempt failed with "ETIMEDOUT - Connection attempt timed out".
425 Failed to establish connection.
How do I solve this problem?
This kind of error typically happens when a data connection cannot be created to transfer files or directory listings. Such data connections are done using dynamic ports, where in case of PASV the port to use is announced by the server within the response to the PASV command.
Firewalls often employ helpers to scan the traffic and look for such responses announcing which port the client should use - and then temporarily allowing such access. In case of plain FTP without encryption the firewall can see the response and determine the port to open - then it works. But, in case of FTPS the control connection is encrypted and therefore the firewall only sees encrypted communication and cannot determine the port to open - then it fails.
I have a pcap file with has the TLSv2.0 traffic from an Windows exe application.
I also have the backend server's private key used to establish the connection.
I have tried both the enabling ssllogfile environment variable and also tried selecting the private key under Wireshark -> Preferences -> TLS. But I still could not decrypt the traffic.
Is there any other way?
The cipher suite used is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
The "ECDHE" means the key exchange is done using Elliptic Curve Diffie-Hellman, which provides forward secrecy. This means that the private key from the server X.509 cert is not enough to decrypt the traffic. You will need to get the client application to generate an SSLKEYLOGFILE, which can be done with Chrome, Firefox and curl. If the "Windows exe application" is something different, then you'll have to intercept the TLS traffic in order to see what goes inside the TLS tunnel.
If you wanna analyze the decrypted traffic in Wireshark, then I'd recommend to proxy the traffic with PolarProxy, because it generates a PCAP file with the decrypted traffic from the TLS session. You will not need any SSLKEYLOGFILE if you choose to intercept and decrypt the TLS traffic with PolarProxy.
I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.
When a Meteor client uses DDP.connect() to connect to a DDP server, it's sent in plaintext. How can we establish SSL encrypted DDP connections?
Meteor relays on SockJs, according to SocksJs README: From SockJS' point of view there is nothing special about SSL/HTTPS. Connecting between unencrypted and encrypted sites should work just fine.
My code:
var connection = DDP.connect("ws://127.0.0.1:3000");
If you switch from ws to wss (WebSocket Secure), if the host supports ssl, it will be used. In my localhost, I don't ssl installed and It doesn't fallback to ´ws´, you've to manually code it if you want so.
I'm working on adding SSL support into our existing application and have started to think about backwards compatibility.
The one special case that makes this different than other posts I've read is the server may not necessarily be updated with SSL code. So I'll have an SSL client connecting to a server that knows nothing about SSL.
For the sake of this discussion, the application sends keystrokes one at a time to the server, and for each keystroke a new socket is created. So I need to figure out a way to make this work on the existing port number and not use timeouts to determine if the server supports SSL or not.
Any suggestions on a graceful way to handle this?
(I'm using Winsock and OpenSSL)
Usually applications accept plain connections and direct SSL connections on different ports, e.g. smtp port 25 and smtps port 465, http port 80 and https port 443 etc. Other ways are to use the same port and then have a specific command from the client to upgrade to SSL, e.g. like STARTTLS with smtp or AUTH TLS with ftp.
If these common ways are not an option for you and the client sends the first packet in your protocol anyway (like with http, but not with smtp or ftp) you might do an recv(..MSG_PEEK) after the initial accept to see, what kind of data the client sends without removing the data from the socket buffer yet. If the peeked data look like your plain application protocol you continue there, if they look like a client hello from SSL (see https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification) you do an SSL upgrade.