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.
Related
I am forcing a dummy SSL for my localhost running through xampp. Now I am using web sockets which asks for 'wss:' instead of 'ws:'. But when using 'wss', I am getting the following Error:
WebSocket connection to 'wss://192.168.1.5/?aswin' failed: WebSocket opening handshake was canceled
I am new to this, I don't know what's causing this issue.
Remember to change the port number to a one different to the one you used for not secure connections. Some browsers get confused if suddenly a port becomes secure or viceversa.
Remember to use the hostname indicated in the certificate to connect and not the IP.
If you are using a self-signed certificate, use it for HTTPS so you can see the dialog for accepting that certificate. When accessing via WSS:// there is not certificate acceptance dialog, it will just fail to connect.
Let's say you want to perform an https request to a certain website but you have a proxy on the middle.
The aforesaid proxy doesn't look into the request but just relay all the traffic to the actual HTTPS server after the user-agent has used the HTTP CONNECT method (as in http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt).
Now my question is the following: after the proxy opens a SSL connection to the destination webserver, should it also upgrade the socket which handles the connection with the client to SSL as well? And if so, how would it forward packets to the server without sniffing the actual content?
What I mean here is that if the proxy actually reads data from SSL client socket and forwards them to SSL server socket, the data will be not encrypted to it.
The proxy has a plaintext connection open to the client, via which it received the CONNECT command. It opens a plaintext connection to the server. Thereafter it just copies bytes in both directions. The bytes coming from both client and server are SSL, so this works without the proxy knowing what's inside the ciphertext.
I just read over node-tls-proxy (http://code.google.com/p/node-tls-proxy/), a https proxy. I like the idea of it, but I'm not getting why this proxy needs a local http server (see the local-proxy.js script).
So I was wondering if this is necessary?
My idea of the proxy was actually like this: Client -> HTTPS Connection to trusted Server/Proxy -> Internets
In this case network sniffing between the Client and the Server wouldn't (hardly) be possible because it would be ssl encrypted.
Thanks,
Seb
If I get the idea correctly, the goal is to set up a "remote" proxy in a location that one trusts to be secure. Your client shall only communicate with this remote proxy using TLS, the remote proxy is then allowed to do the actual (no longer encrypted) HTTP requests.
What you do on the client side now is this: you configure the "local" proxy in your browser. Since you type "http://..." in your browser even when using the proxy, your browser will initiate an unencrypted HTTP connection to the local proxy first. Then the local proxy will open an encrypted TLS connection to the remote proxy and forward your request over a secured channel.
This means you need the local proxy for the purpose of "transforming" HTTP into HTTPS requests because your browser will dutifully only use HTTP when asked to make an actual HTTP request.
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.
I was wondering if When using PROXY, does SSL (through HTTPS) secure the connection from the admins of the proxy, so they will not be able to see the content?
Basically, when doing SSL connections with a proxy, you connect to the proxy and use something like the CONNECT HTTP verb, which just asks the proxy to connect to the remote host on the specified port. At that point, you're not secure; you can assume that the proxy is listening to the conversation. You then start an encrypted session with the remote host, using that host's public key, or rather the remote host uses its private key which you can check against its public key without needing to trust the proxy. The handshake algorithm is such that the proxy can't see what's inside the encrypted channel (since they don't know the session keys that each side picked as part of the SSL protocol). All the proxy can do is inject random detectable noise or cause the connection to get dropped; they can do denial-of-service attacks but can't affect the integrity or secrecy of any information actually transferred.
That's the beauty of using a proper crypto protocol like SSL.