override HTTPS certificate failure

[Peter TB Brett]

On 26/10/2016 14:42, Trevor DeVore wrote:
> On Wed, Oct 26, 2016 at 2:01 AM, Peter TB Brett <peter.brett at livecode.com>
> wrote:
>
>> On 25/10/2016 20:41, Lyn Teyla wrote:
>>
>> 2. If the user elects to trust the certificate, save the certificate
>>> details received from the server during that first connection.
>>>
>>
>> You've forgotten an extremely important step: train the user to be able to
>> distinguish a valid-but-not-trusted certificate from an invalid one. No-one
>> has succededed in doing this, and research has shown that offering users
>> the ability to override certificate validation failures merely trains users
>> to ignore certificate failures.
>>
>> Allowing on-demand verification-skipping is contrary to security best
>> practice and will expose you to risk.
>>
>
> Peter,
>
> I agree that in most cases you don’t want people bypassing these warnings.
> There are situations in software development where people testing software
> against staging servers need to connect over https without the verification
> step. That is why I had to implement it in my custom libURL version.

There are several other enormously superior options.

1. Get 2 certificates, one for staging.yourdomain.com and one for 
www.yourdomain.com.  Then you can test against either at any time 
without needing to disable verification.  "Let's Encrypt" certificates 
are free of charge, and there are lots of ways to prove you own a domain 
other than running a publicly-visible web server.

2. Use the same certificate for both public and staging servers, and 
override the DNS lookup in your engineering environment so that 
www.yourdomain.com resolves to the IP address of the staging server; you 
can do this by editing the "hosts" file, for example.

3. Create your own root certificate and install it on devices that need 
to access the staging server.  This is great if you have a lot of 
internal-visibility-only servers, and is very common in institutional 
environments.

4. If you have internal servers, then you can still use a global 
namespace domain name and "normal" SSL certificates; for example, you 
could register "mydomain-internal.net" and place servers under that 
domain, purchase a wildcard cert for "mydomain-internal.net", and ensure 
that there are never any DNS records published outside your internal 
network for that domain.

So, in almost all situations where you're considering asking people to 
bypass SSL certificate verification, there is a much better solution.


There are two situations in which you may _need_ to bypass SSL cert 
verification:

1. You have a broken corporate proxy running between you and the 
internet that doesn't understand how to proxy SSL connections correctly

2. You have a broken IoT device that simultaneously requires you to use 
HTTPS and forbids HTTP; has an expired, invalid or unsigned certificate; 
and is out of vendor support so you can't complain to them about it

In these two uncommon cases your connection security is pretty much 
unrecoverable, and LiveCode already provides the tools you need to just 
give up and turn SSL cert verification off completely.

                                            Peter

-- 
Dr Peter Brett <peter.brett at livecode.com>
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode