Re: open secure socket... using certificate
If the goal were point-scoring gotchas, that I frequently advocate industry best practices for security redundancy might indeed seem out of place here. I am normally a belt-and-suspenders kinda guy, and I make no apologies for it. Those redundancies usually come up in discussions about exposing databases directly to the open Internet, as opposed to doing the common thing of putting a script between the DB and the connection (which affords the added benefit of allowing us to craft a nice API to help our client dev work move forward more smoothly as well). The distinction is how common the practice is. We see that most systems put a script in front of their DB. And we see that most use localhost sockets without SSL. I'm not inventing any of this. I don't hold an CISSP cert, and I don't manage most of the world's projects. I just see what I see, share what I see, and where I don't understand something I'll ask, like I did here seeking a use-case where the benefit of slowing every socket comm down with encryption and decryption provides a benefit not immediately undone the moment the data is at rest. I still hold that there might be a good use case, but after a brief search on this I was unable to find one, and none has emerged yet even here. In your original post describing this system, you emphasized that LC multiprocessing is being used to find the fastest way to handle the data flow. We generally accept a tradeoff between utility and security, but as with so much of life tradeoffs work best when evaluated for the case at hand. If a user's machine is hosed, it's hosed. If we look for guidance on that from better minds than mine, we can review the practices of leading app and OS vendors. Address space layout randomization may be a good example of how an OS vendor can mitigate risks in compromised machines, but the same OS vendors employing it don't also recommend app devs add their own address randomization at the app level. Maybe app devs should? Maybe OS vendors are lax? The deeper we go down the rabbit hole of protecting systems, the more challenging it gets. At a certain point -- a somewhat shallow point, I don't mind admitting -- I'm happy to leave the deep thinking to specialists and just follow common practice. If I happen to see a risk that common practice doesn't cover, I'll cover it as I go. But even though we have Stuxnet to remind us of the impact of unanticipated consequences from design decisions, if I don't have a specific threat vector in mind AND it's not a common practice, odds are I'll skip it. I admit I'm far less of a programmer than the minds behind Stuxnet. And since most of the world is, I'm okay with that. Security awareness is good, and redundancy common. But where a redundancy is both uncommon and provides little benefit not undone easily elsewhere in the system, I'll often skip it. And when the house is on fire, I'm not sure it's a service to the homeowner to help maintain the illusion that their house isn't on fire. -- Richard Gaskin Fourth World Systems Tom Glod wrote: > Hhahah Richard, that was hilarious. :D Given I've given you next to no > info on the use case, I understand why it may seem overkill, and maybe > it is. > > A wise person once told me and I'm paraphrasing. " you can't > prevent everything so the task at hand is to make things harder > and take longer." That person was you. > > So would it make it harder to steal data if data transport between 2 > decoupled processes was encrypted? you bet. > > Thanks for giving me food for thought...and I will triple check to > make sure its necessary. :D > > > On Mon, Feb 1, 2021 at 6:16 PM Richard Gaskin wrote: > >> Tom Glod wrote: >> >> > Richard, >> > >> > Lets say one of my users is targeted by a hacker and they manage >> > to install a malware process on their system that will capture all >> > the data flowing between the 2 processes. >> > Then they do not need to be sitting in the victim's chair. >> > But if the data was encrypted, this wouldn't matter. >> >> True, that one aspect of your program wouldn't matter. But since >> everything else on the system is now hosed, does anything matter? >> >> To my ear it sounds like a planning committee meeting for a zoo in >> which they're deciding on the steel thickness of armored suits they >> require visitors to wear because tigers are running loose, while >> the whole facility is on fire. I'm in the back of the room raising >> my hand asking if we might just put the tigers back in the cage. >> After we put out the fire. :) >> >> In the scenario you described, what prevents the bad guy from reading >> the data at rest? Or keylogging? Or replacing either or both of the >> executables you delivered? Or anything else they might do once they >> have that level of control throughout the system? >> >> -- >> Richard Gaskin >> Fourth World Systems ___
Re: open secure socket... using certificate
Hhahah Richard, that was hilarious. :D Given I've given you next to no info on the use case, I understand why it may seem overkill, and maybe it is. A wise person once told me and I'm paraphrasing. " you can't prevent everything so the task at hand is to make things harder and take longer." That person was you. So would it make it harder to steal data if data transport between 2 decoupled processes was encrypted? you bet. Thanks for giving me food for thought...and I will triple check to make sure its necessary. :D On Mon, Feb 1, 2021 at 6:16 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Tom Glod wrote: > > > Richard, > > > > Lets say one of my users is targeted by a hacker and they manage > > to install a malware process on their system that will capture all > > the data flowing between the 2 processes. > > Then they do not need to be sitting in the victim's chair. > > But if the data was encrypted, this wouldn't matter. > > True, that one aspect of your program wouldn't matter. But since > everything else on the system is now hosed, does anything matter? > > To my ear it sounds like a planning committee meeting for a zoo in which > they're deciding on the steel thickness of armored suits they require > visitors to wear because tigers are running loose, while the whole > facility is on fire. I'm in the back of the room raising my hand asking > if we might just put the tigers back in the cage. After we put out the > fire. :) > > In the scenario you described, what prevents the bad guy from reading > the data at rest? Or keylogging? Or replacing either or both of the > executables you delivered? Or anything else they might do once they have > that level of control throughout the system? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Mobile:647.562.9411 ___ 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
Re: open secure socket... using certificate
Tom Glod wrote: > Richard, > > Lets say one of my users is targeted by a hacker and they manage > to install a malware process on their system that will capture all > the data flowing between the 2 processes. > Then they do not need to be sitting in the victim's chair. > But if the data was encrypted, this wouldn't matter. True, that one aspect of your program wouldn't matter. But since everything else on the system is now hosed, does anything matter? To my ear it sounds like a planning committee meeting for a zoo in which they're deciding on the steel thickness of armored suits they require visitors to wear because tigers are running loose, while the whole facility is on fire. I'm in the back of the room raising my hand asking if we might just put the tigers back in the cage. After we put out the fire. :) In the scenario you described, what prevents the bad guy from reading the data at rest? Or keylogging? Or replacing either or both of the executables you delivered? Or anything else they might do once they have that level of control throughout the system? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: open secure socket... using certificate
Richard, Lets say one of my users is targetted by a hacker and they manage to install a malware process on their system that will capture all the data flowing between the 2 processes. Then they do not need to be sitting in the victim's chair. But if the data was encrypted, this wouldn't matter. On Mon, Feb 1, 2021 at 4:02 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Tom Glod wrote: > > > On Fri, Jan 29, 2021 at 1:09 AM Richard Gaskin wrote: > >> The main benefit of encrypted sockets is to mitigate man-in-the- > >> middle attacks. > >> > >> If you have a man in the middle of processes on a local computer that > >> isn't you, it would seem you have bigger concerns. ;) > ... > > Hi Richard...the man in the middle attack is exactly the thing I was > > thinking of. > > > It seems I didn't write clearly. > > With localHost the man in the middle is you, or someone else with > physical access to your computer (which is more or less the same thing). > > Given the old adage that physical access = root, I'm unable to think of > a scenario in which encrypting localhost sockets is beneficial. Am I > overlooking something? I'm no CISSP, so I may well be. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Mobile:647.562.9411 ___ 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
Re: open secure socket... using certificate
Tom Glod wrote: > On Fri, Jan 29, 2021 at 1:09 AM Richard Gaskin wrote: >> The main benefit of encrypted sockets is to mitigate man-in-the- >> middle attacks. >> >> If you have a man in the middle of processes on a local computer that >> isn't you, it would seem you have bigger concerns. ;) ... > Hi Richard...the man in the middle attack is exactly the thing I was > thinking of. It seems I didn't write clearly. With localHost the man in the middle is you, or someone else with physical access to your computer (which is more or less the same thing). Given the old adage that physical access = root, I'm unable to think of a scenario in which encrypting localhost sockets is beneficial. Am I overlooking something? I'm no CISSP, so I may well be. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: open secure socket... using certificate
Hi Richard...the man in the middle attack is exactly the thing I was thinking of. On Fri, Jan 29, 2021 at 1:09 AM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Tom Glod wrote: > > > 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. > > SLL encryption/decryption adds overhead to that process. > > > > 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. > > The main benefit of encrypted sockets is to mitigate man-in-the-middle > attacks. > > If you have a man in the middle of processes on a local computer that > isn't you, it would seem you have bigger concerns. ;) > > > > > It would have been nice to reply on the protocol for it. I can get > > around this particular problem of course by encrypting on one side > > and decrypting on the other, also. If I am really paranoid about > > my security. > > Paranoia can be healthy, when taken as directed. There may be a benefit > to encrypting localhost sockets that I'm unfamiliar with, and if someone > can point me to threat vector I'd be grateful to learn. > > But I can't recall seeing a system that uses encrypted comms on local > sockets. > > > > What do you think will be the fastest way? Socket? Open Process? > > Sockets and multiprocessing are such different things I'm pretty sure I > don't understand the usage scenario. But if you can describe we can > brainstorm to optimize, as many good threads here have done before. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Mobile:647.562.9411 ___ 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
Re: open secure socket... using certificate
Xojo is not multi platform. If you want to move, which i regret, I strongly advise you to go for the B4X platform. Get Outlook for Android<https://aka.ms/ghei36> From: use-livecode on behalf of Bernard Devlin via use-livecode Sent: Friday, January 29, 2021 7:19:58 PM To: How to use LiveCode Cc: Bernard Devlin Subject: Re: open secure socket... using certificate Hi Richard The idea of client certificates was why I was looking for this feature for the past 15 years. I know that PKI is complex but it is important (which is why browsers implemented it decades ago). Even tsNet behaves very differently on Windows and OS X when it comes to server certificates (looks to me that Microsoft is mis-implementing their libcurl/schannel interface, but I guess it stung them 20 years ago when they hadn't implemented Certificate Revocation Lists). Without LC having client certificates the only option I face is moving to another tool. Even the idea of implementing real secure sockets in a FFI external would be a huge amount of work for any of us users (as there is not even a single lower level language which we could rely on in each platform, so we'd be implementing a complex security layer and learning how to do it in several different languages). I'm going to look at moving to Xojo. Their docs say they implemented secure sockets with certificates in 2006. Their Android deployment platform is close to completion. It really would have been better for LC to have removed those claims from the Dictionary back in 2014, as then I'd have seen in recent years it still hadn't been implemented and would have looked at another tool months ago rather than get to this point and realise I'd wasted a lot of time. I've spent an entire week now just pondering on the options on how I can move forward. Regards, Bernard On Fri, Jan 29, 2021 at 4:12 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > > > Thank you, Bernard. In bringing myself up to speed on this, once I > stumbled across the phrase "two-way SSL" I was able to find much good > reading about it. > > I just added Comment #11 to the bug report on this: > > The range of services requiring two-way SSL is increasing, > and with IoT the scope of use cases is multiplying. > > Where required, I don't see an opportunity for a scripted > workaround, so in those cases the only alternative is to > leave LC for a tool that supports two-way SSL. > > This would seem a good time to bite the bullet on this > implementation. What would be required to make it happen? > > https://quality.livecode.com/show_bug.cgi?id=13410#c11 > > ___ 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 ___ 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
Re: open secure socket... using certificate
Hi Richard The idea of client certificates was why I was looking for this feature for the past 15 years. I know that PKI is complex but it is important (which is why browsers implemented it decades ago). Even tsNet behaves very differently on Windows and OS X when it comes to server certificates (looks to me that Microsoft is mis-implementing their libcurl/schannel interface, but I guess it stung them 20 years ago when they hadn't implemented Certificate Revocation Lists). Without LC having client certificates the only option I face is moving to another tool. Even the idea of implementing real secure sockets in a FFI external would be a huge amount of work for any of us users (as there is not even a single lower level language which we could rely on in each platform, so we'd be implementing a complex security layer and learning how to do it in several different languages). I'm going to look at moving to Xojo. Their docs say they implemented secure sockets with certificates in 2006. Their Android deployment platform is close to completion. It really would have been better for LC to have removed those claims from the Dictionary back in 2014, as then I'd have seen in recent years it still hadn't been implemented and would have looked at another tool months ago rather than get to this point and realise I'd wasted a lot of time. I've spent an entire week now just pondering on the options on how I can move forward. Regards, Bernard On Fri, Jan 29, 2021 at 4:12 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > > > Thank you, Bernard. In bringing myself up to speed on this, once I > stumbled across the phrase "two-way SSL" I was able to find much good > reading about it. > > I just added Comment #11 to the bug report on this: > > The range of services requiring two-way SSL is increasing, > and with IoT the scope of use cases is multiplying. > > Where required, I don't see an opportunity for a scripted > workaround, so in those cases the only alternative is to > leave LC for a tool that supports two-way SSL. > > This would seem a good time to bite the bullet on this > implementation. What would be required to make it happen? > > https://quality.livecode.com/show_bug.cgi?id=13410#c11 > > ___ 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
Re: open secure socket... using certificate
Bernard Devlin wrote: > On Thu, Jan 28, 2021 at 4:44 PM Richard Gaskin wrote: >> Is this specific to the server "accept" not supporting SSL, >> or something client-side? > > Hi Richard, it's client side. > > The project is a messaging app, principally for mobile. SSL/TLS > certificates issued with client software enable servers to know that > the connection is allowed at a network level before any user > authentication. Thank you, Bernard. In bringing myself up to speed on this, once I stumbled across the phrase "two-way SSL" I was able to find much good reading about it. I just added Comment #11 to the bug report on this: The range of services requiring two-way SSL is increasing, and with IoT the scope of use cases is multiplying. Where required, I don't see an opportunity for a scripted workaround, so in those cases the only alternative is to leave LC for a tool that supports two-way SSL. This would seem a good time to bite the bullet on this implementation. What would be required to make it happen? https://quality.livecode.com/show_bug.cgi?id=13410#c11 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: open secure socket... using certificate
Hi Richard, it's client side. The project is a messaging app, principally for mobile. SSL/TLS certificates issued with client software enable servers to know that the connection is allowed at a network level before any user authentication. In the early stages of development it was simple enough for a LC messaging server to dismiss connections which didn't come from an accepted client and didn't meet the specification. Once I moved to an industry standard server then the connections have to be encrypted with certificates at both ends. Regards, Bernard On Thu, Jan 28, 2021 at 4:44 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Bernard Devlin wrote: > > > I feel like a sucker. I started on this project a few months ago on > > the assumption that socket certificates now worked as they'd been > > included in the Dictionary for years. I was away from development for > > a few years and hadn't noticed the complaints that the Dictionary was > > misrepresenting the situation. > > Is this specific to the server "accept" not supporting SSL, or something > client-side? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > ___ 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
Re: open secure socket... using certificate
Tom Glod wrote: > 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. SLL encryption/decryption adds overhead to that process. > 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. The main benefit of encrypted sockets is to mitigate man-in-the-middle attacks. If you have a man in the middle of processes on a local computer that isn't you, it would seem you have bigger concerns. ;) > It would have been nice to reply on the protocol for it. I can get > around this particular problem of course by encrypting on one side > and decrypting on the other, also. If I am really paranoid about > my security. Paranoia can be healthy, when taken as directed. There may be a benefit to encrypting localhost sockets that I'm unfamiliar with, and if someone can point me to threat vector I'd be grateful to learn. But I can't recall seeing a system that uses encrypted comms on local sockets. > What do you think will be the fastest way? Socket? Open Process? Sockets and multiprocessing are such different things I'm pretty sure I don't understand the usage scenario. But if you can describe we can brainstorm to optimize, as many good threads here have done before. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: open secure socket... using certificate
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 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
Re: open secure socket... using certificate
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. It would have been nice to reply on the protocol for it. I can get around this particular problem of course by encrypting on one side and decrypting on the other, also. If I am really paranoid about my security. What do you think will be the fastest way? Socket? Open Process? I'm still setting up a test for latency and throughput. I will not be testing this for a few months, but when I have results on this experiment, I will report. Thanks for asking I guess, got me thinking about it. Cheers, Tom On Wed, Jan 27, 2021 at 5:49 AM Bernard Devlin via use-livecode < use-livecode@lists.runrev.com> wrote: > Hi Tom > > You shouldn't get any hopes up. I'd commented in the bug report in 2014 > that this was something that we'd been told was coming back in the days of > LC version 2. > > > I think when a development environment has failed to deliver a feature from > version 2 to version 10 that thing is never going to appear. > > > On Tue, Jan 26, 2021 at 9:22 PM Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > super happy to see this, hopefully it will when i need it. > > Going to look this up. > > Wondering if it will be super hard to create certificate and make it work > > on localhost sockets. > > > > > > On Tue, Jan 26, 2021 at 2:26 PM Brian Milby via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > “Using tCertificate and tKey” compiles but I don’t know how to test. > It > > > does seem like the parser doesn’t recognize those keywords. > > > > > > Sent from my iPhone > > > > > > > On Jan 26, 2021, at 2:13 PM, Bernard Devlin via use-livecode < > > > use-livecode@lists.runrev.com> wrote: > > > > > > > > Thanks for the suggestion Erik, but I don't see from that how one > > > specifies > > > > the certificate. > > > > > > > > Regards, Bernard > > > > > > > >> On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < > > > >> use-livecode@lists.runrev.com> wrote: > > > >> > > > >> Maybe this: > > > >> > > > >> secure socket "livecode.com:443" > > > >> > > > >> Examples: > > > >> > > > >> https://livecode.fandom.com/wiki/Secure_socket > > > >> > > > >> -Original Message- > > > >> From: use-livecode On > Behalf > > Of > > > >> Bernard Devlin via use-livecode > > > >> Sent: dinsdag 26 januari 2021 16:40 > > > >> To: How to use LiveCode > > > >> Cc: Bernard Devlin > > > >> Subject: Re: open secure socket... using certificate > > > >> > > > >> I did. I tried these too: > > > >> > > > >> *open* *secure* socket to "localhost:443" using certificate tc and > > key > > > tk > > > >> > > > >> *open* *secure* socket to "localhost:443" without verification using > > > >> certificate tc and key tk > > > >> > > > >> When the above lines are entered in the script editor they are > flagged > > > as > > > >> being syntax errors. In both cases it is what comes after > > "certificate" > > > >> that is flagged as a syntax error (flagged as: missing "," near > "tc"). > > > >> There seems to be no combination of command options that works with > > > >> certificates. > > > >> > > > >> The fact that the Dictionary has zero information about what is > > expected > > > >> for certificate/key was not a good sign, which is why I searched the > > > >> archive. I just went to have a look at the code on Github and I can > > > seen > > > >> nothing to suggest that "using certificate and key" is imple
Re: open secure socket... using certificate
Agreed. All a cert does is guarantee (if I can use such a word in the security realm) that the current host is who they say they are. If simple encryption is needed, just do that. I use unsecured sockets in one of my libraries, but I encrypt the data before I send it, then decrypt it on the other end. Bob S On Jan 28, 2021, at 8:40 AM, Richard Gaskin via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Tom Glod wrote: > Wondering if it will be super hard to create certificate and make it > work on localhost sockets. Pardon my naivete, but what is the value of a secured socket in local socket comms? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ___ 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
Re: open secure socket... using certificate
Bernard Devlin wrote: > I feel like a sucker. I started on this project a few months ago on > the assumption that socket certificates now worked as they'd been > included in the Dictionary for years. I was away from development for > a few years and hadn't noticed the complaints that the Dictionary was > misrepresenting the situation. Is this specific to the server "accept" not supporting SSL, or something client-side? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: open secure socket... using certificate
Tom Glod wrote: > Wondering if it will be super hard to create certificate and make it > work on localhost sockets. Pardon my naivete, but what is the value of a secured socket in local socket comms? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
RE: open secure socket... using certificate
Maybe this is a possible workaround using cURL command-line utility? https://stackoverflow.com/questions/10079707/https-connection-using-curl-from-command-line Just my 2 cents. -Original Message- From: use-livecode On Behalf Of Bernard Devlin via use-livecode Sent: woensdag 27 januari 2021 11:48 To: How to use LiveCode Cc: Bernard Devlin Subject: Re: open secure socket... using certificate Hi Tom You shouldn't get any hopes up. I'd commented in the bug report in 2014 that this was something that we'd been told was coming back in the days of LC version 2. I think when a development environment has failed to deliver a feature from version 2 to version 10 that thing is never going to appear. On Tue, Jan 26, 2021 at 9:22 PM Tom Glod via use-livecode < use-livecode@lists.runrev.com> wrote: > super happy to see this, hopefully it will when i need it. > Going to look this up. > Wondering if it will be super hard to create certificate and make it > work on localhost sockets. > > > On Tue, Jan 26, 2021 at 2:26 PM Brian Milby via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > “Using tCertificate and tKey” compiles but I don’t know how to test. > > It does seem like the parser doesn’t recognize those keywords. > > > > Sent from my iPhone > > > > > On Jan 26, 2021, at 2:13 PM, Bernard Devlin via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > > Thanks for the suggestion Erik, but I don't see from that how one > > specifies > > > the certificate. > > > > > > Regards, Bernard > > > > > >> On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < > > >> use-livecode@lists.runrev.com> wrote: > > >> > > >> Maybe this: > > >> > > >> secure socket "livecode.com:443" > > >> > > >> Examples: > > >> > > >> https://livecode.fandom.com/wiki/Secure_socket > > >> > > >> -Original Message- > > >> From: use-livecode On > > >> Behalf > Of > > >> Bernard Devlin via use-livecode > > >> Sent: dinsdag 26 januari 2021 16:40 > > >> To: How to use LiveCode > > >> Cc: Bernard Devlin > > >> Subject: Re: open secure socket... using certificate > > >> > > >> I did. I tried these too: > > >> > > >> *open* *secure* socket to "localhost:443" using certificate tc > > >> and > key > > tk > > >> > > >> *open* *secure* socket to "localhost:443" without verification > > >> using certificate tc and key tk > > >> > > >> When the above lines are entered in the script editor they are > > >> flagged > > as > > >> being syntax errors. In both cases it is what comes after > "certificate" > > >> that is flagged as a syntax error (flagged as: missing "," near "tc"). > > >> There seems to be no combination of command options that works > > >> with certificates. > > >> > > >> The fact that the Dictionary has zero information about what is > expected > > >> for certificate/key was not a good sign, which is why I searched > > >> the archive. I just went to have a look at the code on Github > > >> and I can > > seen > > >> nothing to suggest that "using certificate and key" is implemented. > > >> > > >> The server and client certificate are working in a browser, so > > >> the > > problem > > >> is definitely on the LC side. > > >> > > >> On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < > > >> use-livecode@lists.runrev.com> wrote: > > >> > > >>> Did you try with “and key tKey”... it does not look like that > > >>> part is optional. > > >>> > > >>> Sent from my iPhone > > >>> > > >>>> On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > > >>> use-livecode@lists.runrev.com> wrote: > > >>>> > > >>>> According to the Dictionary in LC 9.5.1 there is this command: > > >>>> > > >>>> open secure socket [from [localHostName][:localPort]] [to] > > >>>> socketID [with message callbackMessage] [without verification] > > >>>> *[using certificate certificate and key key]* > > >>&
Re: open secure socket... using certificate
Hi Tom You shouldn't get any hopes up. I'd commented in the bug report in 2014 that this was something that we'd been told was coming back in the days of LC version 2. I think when a development environment has failed to deliver a feature from version 2 to version 10 that thing is never going to appear. On Tue, Jan 26, 2021 at 9:22 PM Tom Glod via use-livecode < use-livecode@lists.runrev.com> wrote: > super happy to see this, hopefully it will when i need it. > Going to look this up. > Wondering if it will be super hard to create certificate and make it work > on localhost sockets. > > > On Tue, Jan 26, 2021 at 2:26 PM Brian Milby via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > “Using tCertificate and tKey” compiles but I don’t know how to test. It > > does seem like the parser doesn’t recognize those keywords. > > > > Sent from my iPhone > > > > > On Jan 26, 2021, at 2:13 PM, Bernard Devlin via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > > Thanks for the suggestion Erik, but I don't see from that how one > > specifies > > > the certificate. > > > > > > Regards, Bernard > > > > > >> On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < > > >> use-livecode@lists.runrev.com> wrote: > > >> > > >> Maybe this: > > >> > > >> secure socket "livecode.com:443" > > >> > > >> Examples: > > >> > > >> https://livecode.fandom.com/wiki/Secure_socket > > >> > > >> -Original Message- > > >> From: use-livecode On Behalf > Of > > >> Bernard Devlin via use-livecode > > >> Sent: dinsdag 26 januari 2021 16:40 > > >> To: How to use LiveCode > > >> Cc: Bernard Devlin > > >> Subject: Re: open secure socket... using certificate > > >> > > >> I did. I tried these too: > > >> > > >> *open* *secure* socket to "localhost:443" using certificate tc and > key > > tk > > >> > > >> *open* *secure* socket to "localhost:443" without verification using > > >> certificate tc and key tk > > >> > > >> When the above lines are entered in the script editor they are flagged > > as > > >> being syntax errors. In both cases it is what comes after > "certificate" > > >> that is flagged as a syntax error (flagged as: missing "," near "tc"). > > >> There seems to be no combination of command options that works with > > >> certificates. > > >> > > >> The fact that the Dictionary has zero information about what is > expected > > >> for certificate/key was not a good sign, which is why I searched the > > >> archive. I just went to have a look at the code on Github and I can > > seen > > >> nothing to suggest that "using certificate and key" is implemented. > > >> > > >> The server and client certificate are working in a browser, so the > > problem > > >> is definitely on the LC side. > > >> > > >> On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < > > >> use-livecode@lists.runrev.com> wrote: > > >> > > >>> Did you try with “and key tKey”... it does not look like that part is > > >>> optional. > > >>> > > >>> Sent from my iPhone > > >>> > > >>>> On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > > >>> use-livecode@lists.runrev.com> wrote: > > >>>> > > >>>> According to the Dictionary in LC 9.5.1 there is this command: > > >>>> > > >>>> open secure socket [from [localHostName][:localPort]] [to] socketID > > >>>> [with message callbackMessage] [without verification] *[using > > >>>> certificate certificate and key key]* > > >>>> > > >>>> However I can't get it to work. > > >>>> > > >>>> open secure socket to "localhost:443" using certificate > > >>>> > > >>>> throws a runtime error "no handler: using" > > >>>> > > >>>> If I use > > >>>> > > >>>> open secure socket to "localhost:443" > > >>>> > > >>>&g
Re: open secure socket... using certificate
Thanks for confirming it Mark. I feel like a sucker. I started on this project a few months ago on the assumption that socket certificates now worked as they'd been included in the Dictionary for years. I was away from development for a few years and hadn't noticed the complaints that the Dictionary was misrepresenting the situation. Depressing to see my own name in that bug report from 7 years ago, pointing out that secure sockets with certificates was something that we'd been told was on the horizon in LC version 2, which must have been around 2004. https://quality.livecode.com/show_bug.cgi?id=13410 Regards, Bernard On Wed, Jan 27, 2021 at 12:57 AM Mark Wieder via use-livecode < use-livecode@lists.runrev.com> wrote: > On 1/26/21 6:05 AM, Bernard Devlin via use-livecode wrote: > > > Is it really the case that for the past 6 years LC documentation has been > > misleading people concerning the implementation of certificates for > secure > > socket connections? > > Sadly, yes. > > > > > I notice in the Dictionary the entry for "open socket" in the table of > > options for this command has entries for "certificate" and "key", but > these > > are both empty. As if these features were meant to be implemented but > were > > never implemented and the Dictionary was never updated to remove this > > misleading information. > > > > I just find that hard to believe. > > https://quality.livecode.com/show_bug.cgi?id=13410 > > although the earliest bug report seems to be from 2006: > > https://quality.livecode.com/show_bug.cgi?id=3737 > > -- > Mark Wieder > > ___ 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
Re: open secure socket... using certificate
On 1/26/21 6:05 AM, Bernard Devlin via use-livecode wrote: Is it really the case that for the past 6 years LC documentation has been misleading people concerning the implementation of certificates for secure socket connections? Sadly, yes. I notice in the Dictionary the entry for "open socket" in the table of options for this command has entries for "certificate" and "key", but these are both empty. As if these features were meant to be implemented but were never implemented and the Dictionary was never updated to remove this misleading information. I just find that hard to believe. https://quality.livecode.com/show_bug.cgi?id=13410 although the earliest bug report seems to be from 2006: https://quality.livecode.com/show_bug.cgi?id=3737 -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: open secure socket... using certificate
super happy to see this, hopefully it will when i need it. Going to look this up. Wondering if it will be super hard to create certificate and make it work on localhost sockets. On Tue, Jan 26, 2021 at 2:26 PM Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > “Using tCertificate and tKey” compiles but I don’t know how to test. It > does seem like the parser doesn’t recognize those keywords. > > Sent from my iPhone > > > On Jan 26, 2021, at 2:13 PM, Bernard Devlin via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Thanks for the suggestion Erik, but I don't see from that how one > specifies > > the certificate. > > > > Regards, Bernard > > > >> On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >> > >> Maybe this: > >> > >> secure socket "livecode.com:443" > >> > >> Examples: > >> > >> https://livecode.fandom.com/wiki/Secure_socket > >> > >> -Original Message----- > >> From: use-livecode On Behalf Of > >> Bernard Devlin via use-livecode > >> Sent: dinsdag 26 januari 2021 16:40 > >> To: How to use LiveCode > >> Cc: Bernard Devlin > >> Subject: Re: open secure socket... using certificate > >> > >> I did. I tried these too: > >> > >> *open* *secure* socket to "localhost:443" using certificate tc and key > tk > >> > >> *open* *secure* socket to "localhost:443" without verification using > >> certificate tc and key tk > >> > >> When the above lines are entered in the script editor they are flagged > as > >> being syntax errors. In both cases it is what comes after "certificate" > >> that is flagged as a syntax error (flagged as: missing "," near "tc"). > >> There seems to be no combination of command options that works with > >> certificates. > >> > >> The fact that the Dictionary has zero information about what is expected > >> for certificate/key was not a good sign, which is why I searched the > >> archive. I just went to have a look at the code on Github and I can > seen > >> nothing to suggest that "using certificate and key" is implemented. > >> > >> The server and client certificate are working in a browser, so the > problem > >> is definitely on the LC side. > >> > >> On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >> > >>> Did you try with “and key tKey”... it does not look like that part is > >>> optional. > >>> > >>> Sent from my iPhone > >>> > >>>> On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > >>> use-livecode@lists.runrev.com> wrote: > >>>> > >>>> According to the Dictionary in LC 9.5.1 there is this command: > >>>> > >>>> open secure socket [from [localHostName][:localPort]] [to] socketID > >>>> [with message callbackMessage] [without verification] *[using > >>>> certificate certificate and key key]* > >>>> > >>>> However I can't get it to work. > >>>> > >>>> open secure socket to "localhost:443" using certificate > >>>> > >>>> throws a runtime error "no handler: using" > >>>> > >>>> If I use > >>>> > >>>> open secure socket to "localhost:443" > >>>> > >>>> I get a socket connection, but all the security of a client > >>>> certificate does not work > >>>> > >>>> > >>>> This causes a syntax error in the IDE: > >>>> > >>>> open secure socket to "localhost:443" using certificate tName > >>>> > >>>> Looking through the archives I see that a couple of discussions > >>>> where people were asking about this variant of the "open socket" > >>>> command 5 to 6 years ago, *saying that the "certificate" part has > >>>> not been implemented*, regardless of what the Dictionary says. > >>>> > >>>> Is it really the case that for the past 6 years LC documentation has > >>>> been misleading people concerning the implementation of certificates > &
Re: open secure socket... using certificate
“Using tCertificate and tKey” compiles but I don’t know how to test. It does seem like the parser doesn’t recognize those keywords. Sent from my iPhone > On Jan 26, 2021, at 2:13 PM, Bernard Devlin via use-livecode > wrote: > > Thanks for the suggestion Erik, but I don't see from that how one specifies > the certificate. > > Regards, Bernard > >> On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> Maybe this: >> >> secure socket "livecode.com:443" >> >> Examples: >> >> https://livecode.fandom.com/wiki/Secure_socket >> >> -Original Message- >> From: use-livecode On Behalf Of >> Bernard Devlin via use-livecode >> Sent: dinsdag 26 januari 2021 16:40 >> To: How to use LiveCode >> Cc: Bernard Devlin >> Subject: Re: open secure socket... using certificate >> >> I did. I tried these too: >> >> *open* *secure* socket to "localhost:443" using certificate tc and key tk >> >> *open* *secure* socket to "localhost:443" without verification using >> certificate tc and key tk >> >> When the above lines are entered in the script editor they are flagged as >> being syntax errors. In both cases it is what comes after "certificate" >> that is flagged as a syntax error (flagged as: missing "," near "tc"). >> There seems to be no combination of command options that works with >> certificates. >> >> The fact that the Dictionary has zero information about what is expected >> for certificate/key was not a good sign, which is why I searched the >> archive. I just went to have a look at the code on Github and I can seen >> nothing to suggest that "using certificate and key" is implemented. >> >> The server and client certificate are working in a browser, so the problem >> is definitely on the LC side. >> >> On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> Did you try with “and key tKey”... it does not look like that part is >>> optional. >>> >>> Sent from my iPhone >>> >>>> On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < >>> use-livecode@lists.runrev.com> wrote: >>>> >>>> According to the Dictionary in LC 9.5.1 there is this command: >>>> >>>> open secure socket [from [localHostName][:localPort]] [to] socketID >>>> [with message callbackMessage] [without verification] *[using >>>> certificate certificate and key key]* >>>> >>>> However I can't get it to work. >>>> >>>> open secure socket to "localhost:443" using certificate >>>> >>>> throws a runtime error "no handler: using" >>>> >>>> If I use >>>> >>>> open secure socket to "localhost:443" >>>> >>>> I get a socket connection, but all the security of a client >>>> certificate does not work >>>> >>>> >>>> This causes a syntax error in the IDE: >>>> >>>> open secure socket to "localhost:443" using certificate tName >>>> >>>> Looking through the archives I see that a couple of discussions >>>> where people were asking about this variant of the "open socket" >>>> command 5 to 6 years ago, *saying that the "certificate" part has >>>> not been implemented*, regardless of what the Dictionary says. >>>> >>>> Is it really the case that for the past 6 years LC documentation has >>>> been misleading people concerning the implementation of certificates >>>> for >>> secure >>>> socket connections? >>>> >>>> I notice in the Dictionary the entry for "open socket" in the table >>>> of options for this command has entries for "certificate" and "key", >>>> but >>> these >>>> are both empty. As if these features were meant to be implemented >>>> but >>> were >>>> never implemented and the Dictionary was never updated to remove >>>> this misleading information. >>>> >>>> I just find that hard to believe. >>>> >>>> Regards >>>> >>>> Bernard >>>> __
Re: open secure socket... using certificate
Thanks for the suggestion Erik, but I don't see from that how one specifies the certificate. Regards, Bernard On Tue, Jan 26, 2021 at 6:03 PM Erik Beugelaar via use-livecode < use-livecode@lists.runrev.com> wrote: > Maybe this: > > secure socket "livecode.com:443" > > Examples: > > https://livecode.fandom.com/wiki/Secure_socket > > -Original Message- > From: use-livecode On Behalf Of > Bernard Devlin via use-livecode > Sent: dinsdag 26 januari 2021 16:40 > To: How to use LiveCode > Cc: Bernard Devlin > Subject: Re: open secure socket... using certificate > > I did. I tried these too: > > *open* *secure* socket to "localhost:443" using certificate tc and key tk > > *open* *secure* socket to "localhost:443" without verification using > certificate tc and key tk > > When the above lines are entered in the script editor they are flagged as > being syntax errors. In both cases it is what comes after "certificate" > that is flagged as a syntax error (flagged as: missing "," near "tc"). > There seems to be no combination of command options that works with > certificates. > > The fact that the Dictionary has zero information about what is expected > for certificate/key was not a good sign, which is why I searched the > archive. I just went to have a look at the code on Github and I can seen > nothing to suggest that "using certificate and key" is implemented. > > The server and client certificate are working in a browser, so the problem > is definitely on the LC side. > > On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Did you try with “and key tKey”... it does not look like that part is > > optional. > > > > Sent from my iPhone > > > > > On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > > According to the Dictionary in LC 9.5.1 there is this command: > > > > > > open secure socket [from [localHostName][:localPort]] [to] socketID > > > [with message callbackMessage] [without verification] *[using > > > certificate certificate and key key]* > > > > > > However I can't get it to work. > > > > > > open secure socket to "localhost:443" using certificate > > > > > > throws a runtime error "no handler: using" > > > > > > If I use > > > > > > open secure socket to "localhost:443" > > > > > > I get a socket connection, but all the security of a client > > > certificate does not work > > > > > > > > > This causes a syntax error in the IDE: > > > > > > open secure socket to "localhost:443" using certificate tName > > > > > > Looking through the archives I see that a couple of discussions > > > where people were asking about this variant of the "open socket" > > > command 5 to 6 years ago, *saying that the "certificate" part has > > > not been implemented*, regardless of what the Dictionary says. > > > > > > Is it really the case that for the past 6 years LC documentation has > > > been misleading people concerning the implementation of certificates > > > for > > secure > > > socket connections? > > > > > > I notice in the Dictionary the entry for "open socket" in the table > > > of options for this command has entries for "certificate" and "key", > > > but > > these > > > are both empty. As if these features were meant to be implemented > > > but > > were > > > never implemented and the Dictionary was never updated to remove > > > this misleading information. > > > > > > I just find that hard to believe. > > > > > > Regards > > > > > > Bernard > > > ___ > > > 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 > > > > ___ > > 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 > > > ___ > 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 > > > ___ > 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 > ___ 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
RE: open secure socket... using certificate
Maybe this: secure socket "livecode.com:443" Examples: https://livecode.fandom.com/wiki/Secure_socket -Original Message- From: use-livecode On Behalf Of Bernard Devlin via use-livecode Sent: dinsdag 26 januari 2021 16:40 To: How to use LiveCode Cc: Bernard Devlin Subject: Re: open secure socket... using certificate I did. I tried these too: *open* *secure* socket to "localhost:443" using certificate tc and key tk *open* *secure* socket to "localhost:443" without verification using certificate tc and key tk When the above lines are entered in the script editor they are flagged as being syntax errors. In both cases it is what comes after "certificate" that is flagged as a syntax error (flagged as: missing "," near "tc"). There seems to be no combination of command options that works with certificates. The fact that the Dictionary has zero information about what is expected for certificate/key was not a good sign, which is why I searched the archive. I just went to have a look at the code on Github and I can seen nothing to suggest that "using certificate and key" is implemented. The server and client certificate are working in a browser, so the problem is definitely on the LC side. On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > Did you try with “and key tKey”... it does not look like that part is > optional. > > Sent from my iPhone > > > On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > According to the Dictionary in LC 9.5.1 there is this command: > > > > open secure socket [from [localHostName][:localPort]] [to] socketID > > [with message callbackMessage] [without verification] *[using > > certificate certificate and key key]* > > > > However I can't get it to work. > > > > open secure socket to "localhost:443" using certificate > > > > throws a runtime error "no handler: using" > > > > If I use > > > > open secure socket to "localhost:443" > > > > I get a socket connection, but all the security of a client > > certificate does not work > > > > > > This causes a syntax error in the IDE: > > > > open secure socket to "localhost:443" using certificate tName > > > > Looking through the archives I see that a couple of discussions > > where people were asking about this variant of the "open socket" > > command 5 to 6 years ago, *saying that the "certificate" part has > > not been implemented*, regardless of what the Dictionary says. > > > > Is it really the case that for the past 6 years LC documentation has > > been misleading people concerning the implementation of certificates > > for > secure > > socket connections? > > > > I notice in the Dictionary the entry for "open socket" in the table > > of options for this command has entries for "certificate" and "key", > > but > these > > are both empty. As if these features were meant to be implemented > > but > were > > never implemented and the Dictionary was never updated to remove > > this misleading information. > > > > I just find that hard to believe. > > > > Regards > > > > Bernard > > ___ > > 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 > > ___ > 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 > ___ 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 ___ 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
Re: open secure socket... using certificate
I did. I tried these too: *open* *secure* socket to "localhost:443" using certificate tc and key tk *open* *secure* socket to "localhost:443" without verification using certificate tc and key tk When the above lines are entered in the script editor they are flagged as being syntax errors. In both cases it is what comes after "certificate" that is flagged as a syntax error (flagged as: missing "," near "tc"). There seems to be no combination of command options that works with certificates. The fact that the Dictionary has zero information about what is expected for certificate/key was not a good sign, which is why I searched the archive. I just went to have a look at the code on Github and I can seen nothing to suggest that "using certificate and key" is implemented. The server and client certificate are working in a browser, so the problem is definitely on the LC side. On Tue, Jan 26, 2021 at 2:34 PM Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > Did you try with “and key tKey”... it does not look like that part is > optional. > > Sent from my iPhone > > > On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > According to the Dictionary in LC 9.5.1 there is this command: > > > > open secure socket [from [localHostName][:localPort]] [to] socketID [with > > message callbackMessage] [without verification] *[using certificate > > certificate and key key]* > > > > However I can't get it to work. > > > > open secure socket to "localhost:443" using certificate > > > > throws a runtime error "no handler: using" > > > > If I use > > > > open secure socket to "localhost:443" > > > > I get a socket connection, but all the security of a client certificate > > does not work > > > > > > This causes a syntax error in the IDE: > > > > open secure socket to "localhost:443" using certificate tName > > > > Looking through the archives I see that a couple of discussions where > > people were asking about this variant of the "open socket" command 5 to 6 > > years ago, *saying that the "certificate" part has not been implemented*, > > regardless of what the Dictionary says. > > > > Is it really the case that for the past 6 years LC documentation has been > > misleading people concerning the implementation of certificates for > secure > > socket connections? > > > > I notice in the Dictionary the entry for "open socket" in the table of > > options for this command has entries for "certificate" and "key", but > these > > are both empty. As if these features were meant to be implemented but > were > > never implemented and the Dictionary was never updated to remove this > > misleading information. > > > > I just find that hard to believe. > > > > Regards > > > > Bernard > > ___ > > 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 > > ___ > 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 > ___ 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
Re: open secure socket... using certificate
Did you try with “and key tKey”... it does not look like that part is optional. Sent from my iPhone > On Jan 26, 2021, at 9:07 AM, Bernard Devlin via use-livecode > wrote: > > According to the Dictionary in LC 9.5.1 there is this command: > > open secure socket [from [localHostName][:localPort]] [to] socketID [with > message callbackMessage] [without verification] *[using certificate > certificate and key key]* > > However I can't get it to work. > > open secure socket to "localhost:443" using certificate > > throws a runtime error "no handler: using" > > If I use > > open secure socket to "localhost:443" > > I get a socket connection, but all the security of a client certificate > does not work > > > This causes a syntax error in the IDE: > > open secure socket to "localhost:443" using certificate tName > > Looking through the archives I see that a couple of discussions where > people were asking about this variant of the "open socket" command 5 to 6 > years ago, *saying that the "certificate" part has not been implemented*, > regardless of what the Dictionary says. > > Is it really the case that for the past 6 years LC documentation has been > misleading people concerning the implementation of certificates for secure > socket connections? > > I notice in the Dictionary the entry for "open socket" in the table of > options for this command has entries for "certificate" and "key", but these > are both empty. As if these features were meant to be implemented but were > never implemented and the Dictionary was never updated to remove this > misleading information. > > I just find that hard to believe. > > Regards > > Bernard > ___ > 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 ___ 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