Server certificate hash checking

[Nikos Mavrogiannopoulos]

On Wed, 2014-12-31 at 09:21 +0000, David Woodhouse wrote:
> > This unfortunately had the issues summarized in David's email above. A
> > certificate has signed and unsigned parts, meaning it can be modified so
> > different fingerprints can refer to the same certificate, and a renewed
> > certificate will have a different fingerprint by design.
> 
> But that's not a problem in this case. We are only talking about using the
> full sha1 in the UI for comparison with what the sysadmin wrote on a
> post-it note, or what Firefox on a different machine shows in its
> certificate info UI after it accepted the cert properly through the CA
> that *is* installed there (remember, Kevin's focus is Android where
> installing a new CA is a PITA and now seems to produce constant
> "reminders" that your device is insecure and can be MITM-ed).
> We are still going to actually *store* the new pubkey hash, and use that
> for later connections.

I think it will be confusing to use a different ID for the software to
detect a changed certificate and another for a human. It would also
raise questions why the human is not prompted even if the SHA1
fingerprint changed (e.g., in a certificate change). In addition it
would not solve different openconnect clients printing different
fingerprints.

Maybe we could use both in the UIs to avoid such issues, but I'd
strongly suggest to move to Key IDs.

regards,
Nikos