open secure socket... using certificate
bdrunrev at gmail.com
Fri Jan 29 13:19:58 EST 2021
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.
On Fri, Jan 29, 2021 at 4:12 PM Richard Gaskin via use-livecode <
use-livecode at 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?
More information about the use-livecode