With SSL the encryption occurs at the socket level, that is the socket is secured by virtue of it’s creation. With StartTLS, also an SSL protocol, the socket is first established, then a secure tunnel is created. (Transport Layer Security)
My point? The socket connection itself does not need to be secured, and indeed it’s less desirable if it is. An SSL encrypted certificate must be passed at least once so that host and client both have the public and private key. This is necessary when the host is unknown. To Richard’s point, if you control the host AND the client, a certificate is not needed. You KNOW the host is secure. Simply pass encrypted traffic over an unsecured socket. The result is the same, only nothing about the method is ever passed over the socket connection. I may misunderstand though. Bob S On Jan 28, 2021, at 7:46 PM, Tom Glod via use-livecode <use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote: well..that was short lived. bummer I guess, esp if you really need it in that form. I would ask about it and try to get an answer in clear terms from the team. Richard..... in the labs ...... I am testing the viability of using Livecode as ONLY a UI layer. So I have to find the fastest way of getting decrypted JSON data from Core process (Go binary) to the UI Layer that is a LC stack. So when communicating data via the localhost or socket, I figured it should still be encrypted if possible when in transit between the 2 programs. It's an attack vector in this kind of a scenario, a local one, not remote as much. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
