Re: open secure socket... using certificate

2021-02-02 Thread Richard Gaskin via use-livecode
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

2021-02-02 Thread Tom Glod via use-livecode
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

2021-02-01 Thread Richard Gaskin via use-livecode

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

2021-02-01 Thread Tom Glod via use-livecode
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

2021-02-01 Thread Richard Gaskin via use-livecode

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

2021-01-29 Thread Tom Glod via use-livecode
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

2021-01-29 Thread e.beugelaar--- via use-livecode
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

2021-01-29 Thread Bernard Devlin via use-livecode
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

2021-01-29 Thread Richard Gaskin via use-livecode

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

2021-01-29 Thread Bernard Devlin via use-livecode
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

2021-01-28 Thread Richard Gaskin via use-livecode

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

2021-01-28 Thread Bob Sneidar via use-livecode
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

2021-01-28 Thread Tom Glod via use-livecode
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 implemented.
> > > >>

Re: open secure socket... using certificate

2021-01-28 Thread Bob Sneidar via use-livecode
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

2021-01-28 Thread Richard Gaskin via use-livecode

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

2021-01-28 Thread Richard Gaskin via use-livecode

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

2021-01-28 Thread Erik Beugelaar via use-livecode
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

2021-01-27 Thread Bernard Devlin via use-livecode
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"
> > >>>>
> > >>>> I get a socket connect

Re: open secure socket... using certificate

2021-01-27 Thread Bernard Devlin via use-livecode
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

2021-01-26 Thread Mark Wieder via use-livecode

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

2021-01-26 Thread Tom Glod via use-livecode
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

2021-01-26 Thread Brian Milby via use-livecode
“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

2021-01-26 Thread Bernard Devlin via use-livecode
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

2021-01-26 Thread Erik Beugelaar via use-livecode
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

2021-01-26 Thread Bernard Devlin via use-livecode
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

2021-01-26 Thread Brian Milby via use-livecode
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