override HTTPS certificate failure

[Lyn Teyla]

Bob Sneidar wrote:

> True, but isn't the issue that a malformed cert including self signed certs are rejected? A self signed cert is not insecure, it's just less secure than a root signed cert, and only because a background check has been done against the cert owner. Otherwise a self signed cert is just as valid if you know you can trust it, as when connecting to you domain controller or copier for the first time on a LAN. After that, the cert theoretically cannot be spoofed.

That only applies if the client app is specifically coded to _also_ perform the following additional steps:

1. When connecting to a secure server and receiving invalid and unknown certificate details, present them to the user and allow them to trust or reject the certificate.

2. If the user elects to trust the certificate, save the certificate details received from the server during that first connection.

3. During subsequent connections, compare the saved certificate details to those received, and only proceed if the details are identical.

This is what web browsers, email clients and FTP apps do when instructed by a user to trust an invalid certificate.

libURL doesn’t currently offer a handler that allows one to retrieve certificate data, so one would need to utilize raw sockets or call a command line utility such as openssl to obtain the data.

Simply setting libURLSetSSLVerification to false (even just for specific hosts) doesn’t do any of that, which is why spoofing could still occur.

Lyn