On 26/10/2016 14:42, Trevor DeVore wrote:
On Wed, Oct 26, 2016 at 2:01 AM, Peter TB Brett <peter.br...@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.br...@livecode.com>
LiveCode Technical Project Manager
lcb-mode for Emacs: https://github.com/peter-b/lcb-mode
_______________________________________________
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
