override HTTPS certificate failure

Charles Warwick charles at techstrategies.com.au
Tue Oct 25 23:43:23 EDT 2016


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 <monte at appisle.net> wrote:
>
>>> On 26 Oct. 2016, at 3:25 am, Trevor DeVore <lists at 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?
>





More information about the use-livecode mailing list