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



_______________________________________________
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

Reply via email to