Server certificate hash checking

[David Woodhouse]

> 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.

> Wouldn't it help to get the new key fingerprint using a command of
> openconnect?

Not sure. You might not even have openconnect on the machine that can
verify the cert.

>> So maybe we need a new library function to return the old
>> (standardized) hash, and once that is accepted through the UI, cache
>> the pubkey hash and use that for future comparisons?
>
> That would certainly be possible, but will lead to more confusion than
> solving. Some programs will be using the old hash and others the new
> defeating the purpose of a fingerprint.


No, the old hash should only ever be used by the *user* in the case that
the happen to have a sha1 obtained by other out-of-band means. Just
putting it into the textual output of the
openconnect_get_peer_cert_details() function would almost suffice, except
that Kevin didn't want to show his users that whole thing.

-- 
dwmw2