Monte, Trevor,
My preference for handling the overriding of HTTPS certificates would be
by adding the ability within libUrl to "get" the SSL certificate of a
particular site (for example a self-signed one), and then "add" that SSL
certificate to a CA store that is utilised by the libUrl library.
This would allow you to retrieve the SSL certificates for any
self-signed sites and add them to the CA store during your application's
startup. Then you can use libUrl as normal (with
libUrlSetSSLVerification set to true) and those self-signed sites would
be accessible.
The advantage of this is that it would provide the same benefit that
Trevor is looking to achieve while still providing any application with
protection from SSL connections being hijacked even if they are using
self-signed certificates, rather than completing disregarding the
signing identity of communications.
tsNet currently does allow you to specify a separate CA store than the
system one. If you are writing an application that connects to a server
that is self-signed, then you can download the server's certificate and
call tsNetCABundle with that certificate file. This will allow your
application to verify that the self-signed certificate is the same as
what you downloaded when you make requests against that server.
It is on my task list to create another function in tsNet that allows
you to retrieve the SSL certificates for a specific connection so that
you don't have to download them separately.
As a side note (for anyone that needs this right now), tsNet copies the
tsNetVerifySSLPeer (and tsNetCABundle) setting that is current at the
time a tsNetGet (or any other tsNet* call) function is called and stores
it with the request. This means you can change those settings at any
time and it won't affect any requests already in progress. So if you
want to leave SSL verification on and *just* disable it for one request,
you can simply do:
tsNetVerifySSLPeer false
tsNetGet(....)
tsNetVerifySSLPeer true
Regards,
Charles
On 26/10/2016 10:24 AM, Trevor DeVore wrote:
On Tue, Oct 25, 2016 at 2:36 PM, Monte Goulding <mo...@appisle.net> wrote:
On 26 Oct. 2016, at 3:25 am, Trevor DeVore <li...@mangomultimedia.com>
wrote:
https://github.com/trevordevore/livecode/commit/
6a5bc42abebca23e6b8aa611c8f0966b221441c6 <https://github.com/
trevordevore/livecode/commit/6a5bc42abebca23e6b8aa611c8f0966b221441c6>
One thing I might as well say now as I’ll say it in review anyway is it
would be better to set individual hosts rather than the entire list in one
hit to reduce the risk of different user code clobbering each other.
The intended use of libURLGetServersThatBypassCertificateVerification and
libURLSetServersThatBypassCertificateVerification is for getting servers to
store with your app prefs and for restoring the saved settings when your
app starts up. I still need to add a handler that adds to the list.
It will also be simpler to use:
- get url
- verification failure
- ask user if they want to trust the host anyway
- turn off verification for that host
In my original implementation in my custom version of libURL I set up a
repeat loop around the code that fetches data from the server. My libURL
library allows you to define a callback that would be called if an SSL
cert error occurred. I would display a dialog that looks similar to the one
you see in Safari and let the user decide. The logic looks like this:
repeat
get url
no errors? exit repeat
did an ssl error occur?
is a callback defined?
send the callback
did user say bypass? add to list of servers that ignore
verification and try again in next repeat loop
did user say cancel? exit repeat
end repeat
It got the job done for what I needed. I am a little hesitant to add it in
to libURL as I’m not entirely sure of the implications of the repeat loop.
I was going to start with adding the ability to get/set the servers and add
a server to the list. That way a developer could check the result
themselves and prompt the user.
Ideally it would all happen from within libURL though. I’m not sure I have
the time to think through all of the implications and do the testing
necessary to submit the change to libURL.
Thoughts?
_______________________________________________
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
