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
