override HTTPS certificate failure

[Monte Goulding]

Perhaps this in addition to a callback / dialog?

> On 26 Oct. 2016, at 2:43 pm, Charles Warwick <charles at techstrategies.com.au> wrote:
> 
> 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?
>> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode