On 27/10/2016 9:19 AM, Charles Warwick wrote:
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.
Just reading what I wrote again now, I should just clarify that when I
proposed a function to "add" a certificate to a CA store for libUrl, I
am not implying to add it to the system CA store or even to another CA
store permanently.
What I am suggesting is a function that allows a certificate to be
stored in a temporary CA store "in ram" that is used as part of the
verification process by libUrl while the application is running. The
next time the app runs (or anything else on the system), the certificate
is no longer stored and verification will fail again (which is why it
needs to be added on runtime).
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.
Hopefully my clarification makes this more clear. The "unverified
certificate" is not permanently stored anywhere, however it is
temporarily stored to ensure all accesses across the current running
application hit the same server.
Cheers,
Charles
_______________________________________________
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
