Https, sslVerification, certificates - huh?

[Terry Judd]

Thanks Andre - that gives me some confidence that proceeding without the certificates is OK (i.e. the data is still encrypted) because really all I'm concerned about is that the username and password data I send to each of the sites isn't visible to snoopers. Having said that I'm still confused about the whole certificates thing. LiveCode 4.5 is supposed to automatically find the root certificates you have installed on your system and start using them but this doesn't appear to happen? even though the example in the release note (fetching https://google.com) seems to work. I guess the ideal situation would be for LC to behave more like Firefox, which seems to (without fail and quite transparently) detect when a certificate is required/on offer and 
gives you the option of putting it into use.

Best regards,

Terry... 

On 26/10/2010, at 12:12 AM, "Andre Garzia" <andre at andregarzia.com> wrote:

> Terry,
> 
> There are two different things happening here. One is SSL encryption which
> protects the communication between your machine and the remote machine, the
> other is user authentication that protects the other machine from
> unauthorized access.
> 
> For LiveCode to trust/accept an SSL certificate as verified, it must be
> issued by some certificate authority (CA) that is known. Most operating
> systems come with a list of known CA or something similar, sorry for my lack
> of proper terminology but I can't recall the name of that file. If you try
> establish a connection to a secure server and the certificate provided by
> that server is not from a known CA due to one of the possible facts:
> 
> * that the CA file is outdated or not found
> * the remote guys used some CA that is not common and not on most CA files
> * the remote guys are using a self-signed certificate meaning they are
> acting like their own authority.
> 
> This will trigger an error on the SSL library, not an untrusted connection
> or encryption error but a CA verification error. The connection still works
> and is secure but the certificate can't be verified. Basically it is an
> error of the type "we don't know who issued this damn thing so we're
> screaming".
> 
> You're still protected in terms of a technical standpoint. Checking out the
> error spilled by libURL might help you understand what is actually happening
> such as "is it self-signed", "is it expired"... but the SSL connection will
> still hold.
> 
> When you use set libURLSetVerification to False you're just bypassing this
> verification step and jumping to the actual business of "hey machine, just
> encrypt this damn connection will you!".
> 
> The authentication side happens on another layer. After the secure
> connection is stablished and that is TCP/IP juggling bytes like those street
> magicians, you will face the HTTP Authentication layer which is like that
> really big bouncer at the front door of that club you want to enter. If you
> passed the magician with the really entangled bytes, then, you need to
> present your credentials to the bouncer or you will not be allowed in.
> Different things on the same street but you need to pass from one to the
> other to arrive at your desired destination.
> 
> Hope this helps
> andre "Question the Certificate Authority!!!" garzia
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution