LiveCode Forums

I am developing an livecode app that provides data to my website, on demand. I'm building a socket server, have my SSL certificate from letsencrypt (it works with https from my computer) and I now need to establish a secure socket connection to the incoming wss:// request from the website.

livecode (socket server)
accept connections on port 443 with message "someoneConnected"
secure socket "443" with verification for host "xxx"

javascript on website (socket client)
var websocket = new WebSocket(myserver);

My LC socket server receives the connection and host-side javascript from my website reports

(index):22 WebSocket connection to 'wss://(myserver)/' failed: Error in connection establishment: net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I looked at the post "Accepting only secure connections with sockets" and downloaded the examples mentioned but the "secure socket" line was commented out in the server example.
I'm thinking that I need to explicitly set the sslCertificates but letsencrypt doesn't use .crt files.

How can I use my existing (valid) letsencrypt for secure socket connections?

Oh, yeah, I forgot to mention

I'm running Mac OS X 10_14_6
Livecode Indy 9_5_1 Build 15505

I also tried

accept connections on port 443 with message "someoneConnected"
secure socket "443" without verification

and

accept connections on port 443 with message "someoneConnected"
secure socket "443"

neither helped... both failed with the CIPHER_MISMATCH

It's perhaps worthwhile to point-out that the data received without specifying "secure socket" looks like this

10.0.1.100:63014: ¸}µVÓ‘BoCÌ.åèQGnB˵^åᵉ†l¯?ã{ âTˇ)[0ŒúaúœÛuÈq±Ior5ÀüìZ˚ˇhs~"JJ¿+¿/¿,¿0éî¿¿úù/5

10.0.1.100:63014: ëÍÍmyhostname.comˇ

10.0.1.100:63014:

10.0.1.100:63014: ∫∫#
3+)∫∫ °ù`âQ!)›/ò˜ˆnó÷oÒ;ú+aæ…pÇ^§+º>-+

So the incoming connection local IP is "in the clear" but the rest of the data is encrypted

I believe the "secure socket" command is for client connections, not for server "accept" sockets.

I discovered that the REAL problem here is that LC supports sockets, NOT web sockets.
I need to use other (simpler) function on my website client to do the connection.

my ignorance

Doh! I completely missed the part where you were trying to use websockets.
Yeah, that's been on the enhancement request list for quite a while.

In the name of internet security, websockets are THE allowable client/server method (using ws and wss protocols).
(note: this is way different from low-level tcpsockets which are not accessible from Javascript as best I know)
Now that I have my app receiving connection requests "ALL" that I need is a Livecode stack that speaks wss protocol...
What seemed to me to be a straightforward task (exchanging small bits of data on demand from a website to a LC server)
the protocol becomes the tail that wags the dog.

While I decide if I have the inclination to write an entire ws protocol stack in LC (I don't think that I do) I'll be looking at alternatives.

True, standard TCP sockets would be problematic in a browser, which is why WebSockets were created, a means of providing a full-duplex channel that in some cases can outperform long polling.

But I've been unable to turn up anything about greater security of WebSockets vs standard sockets outside the browser. What should I be searching for?

I'm all for greater internet security. Websockets seems to be the de facto standard. In order to use websockets to exchange data with your PC/Mac running Livecode one needs a WS/WSS stack to implement the protocol you see when you accept a connection in LC. Such work is left as an exercise to the student, perhaps there's a stack somewhere out there that implements this, it's no trivial task, let me know if you find one. Livecode WSS Server stack is what it is, who knows what it would be called.

I'm familiar with what websockets are. I was hoping to find info on how they're more secure than common sockets.

Section 10.3 or the RFC is particularly relevant here, as "Clients MUST choose a new masking key for each frame", but section 1.3 by itself is an abstract of the security issues re the handshake mechanism.

https://tools.ietf.org/html/rfc6455

mwieder wrote: ↑

Wed Feb 26, 2020 5:48 am

Section 10.3 or the RFC is particularly relevant here, as "Clients MUST choose a new masking key for each frame", but section 1.3 by itself is an abstract of the security issues re the handshake mechanism.

https://tools.ietf.org/html/rfc6455

Mark, you know these things better than I do, so help me understand: does that imply WebSockets are more secure than regular sockets, less secure, or more secure of specific additional steps are taken, or something else?

I think that's a bit of an apples-and-oranges comparison: sockets are at a lower network layer than websockets. Websockets are (IIRC) at the same layer as http, so that might be a better protocol to compare. Raw sockets are much lower and serve a different purpose, but websockets rely on tcp which relies on sockets.

By default websockets offer more security features than http does by default. I realize that's not quite the question you asked.