override HTTPS certificate failure

[Charles Warwick]

On 27/10/2016 1:16 AM, Peter TB Brett wrote:
> On 26/10/2016 15:42, Trevor DeVore wrote:
>> Perhaps, but for testing purposes we don’t really care about 
>> implementing
>> them :-) Here is my question for you - are you arguing that LiveCode (a
>
> You probably should care about implementing them.  I can think of 
> several ways to exploit this situation, especially if your test 
> servers are not on the same private network as the developers who are 
> accessing them.
>
That isn't feasible if the app developer has no control over the web 
servers that they are connecting to.  It is common for an app developer 
to have to write an application to communicate with servers that are not 
under their control.  While they can recommend the server administrator 
to implement those things, when it comes to demonstrating an app in a 
testing environment in order to get paid, I think most developers would 
agree that they would prefer to not push too hard!

>> development tool) should not have the ability to allow a developer to
>> create an application that allows a self-signed certificated that 
>> can’t be
>> verified to bypass the verification process for that particular server?
>
> Not at all! I'm saying that LiveCode already does provide the 
> capability.  So there's no need to assemble a massive cannon, load it 
> with explosive shells, and point it at our less security-conscious 
> LiveCode developers' end-users.
>
> I believe that it's a fantastic idea to deprecate 
> libUrlSetSSLVerification, replacing it with a more fine-grained 
> property that lets you select specific hosts!  It would be even better 
> to couple this with a way to make libURL _only_ accept a specific, 
> predefined certificate for a particular host (sort of the opposite of 
> disabling verification) -- "certificate pinning", basically.
>
That is what I was getting at by adding a function to libUrl to add a 
certificate to the CA store used by libUrl.  That way the usual hostname 
verification will take place, along with the verification of the 
certificate.

If the developer can download (and verify) the self-signed certificate 
in advance, store it with the app and load it as an "added" certificate 
to libUrl on runtime, it is more secure than disabling verification for 
a host.

> I believe that it's a bad idea to give LiveCode a built-in "feature" 
> for making it easy for app end-users to ignore cert verification 
> failures.
>
I agree here too.

> I believe that it's a really really bad idea to download completely 
> unverified certificates and permanently add them to the list of certs 
> that your app trusts implicitly.
>
Actually, while it isn't a good idea (any avoidance of verification is 
bad), it is a lot better than disabling SSL verification completely for 
a host.  If, as my last e-mail suggested, a cert is downloaded and then 
added to the CA store of the app at runtime, then it at least ensures 
that for the entire time that the app is running, it is talking to the 
same server.

(Note that in all cases including using real certificates, if a SSL 
certificate is compromised, you don't have any guarantees!)

Completely disabling SSL verification for the host means that while the 
app is running, you could potentially be communicating with different 
servers without realising it.  The app may make some initial 
communication with the correct server, and then via a DNS attack (or 
something else), the next connection with that site could be with a 
malicious server instead.

This is particularly dangerous as the app may send confidential data in 
the second connection that it retrieved from the real server during its 
initial communications.

That aside, adding the ability in libUrl to download and install a 
certificate at runtime doesn't automatically imply that it is going to 
be unverified.  There are many other methods an app can use to verify 
that a certificate is valid (for example, by using their own trusted 
third party site/application to verify the certificate contents).  This 
allows an app developer to use their own means of PKI infrastructure.

Forcing them to have to use something like LetsEncrypt if they don't 
want to pay for SSL certificates simply removes choice.

Ultimately, I don't think Livecode should restrict the means that SSL 
verification can occur.  At this point in time, it really only provides 
two options which are at completely opposite ends of the spectrum:

1.  the certificate has to be signed by an authority that is trusted by 
the whole device (the system's CA bundle)
2.  no verification is performed at all

Cheers,

Charles


>                                                Peter
>