override HTTPS certificate failure

[Charles Warwick]

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