On Tue, 2014-12-30 at 22:27 -0800, Kevin Cernekee wrote: > So, I finally got around to integrating the new library on the Android > side, and I was wondering how you envisioned the UI working. > With the old API, I was able to request a SHA1 of the whole > certificate DER and present that to the user. They could compare the > SHA1 to the output from e.g. "openssl x509 -fingerprint -sha1 -in > foo.pem" or "View Certificate" in Firefox. The known-good SHA1 could > also be provided by a sysadmin, posted on a sticky note, or read off > over the phone. This fingerprinting convention is reasonably standard > across different clients and OSes. 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. You can get that fingerprint in the openconnect certificate info page, but also using gnutls' certtool. In any case it would be good to send a patch to openssl to print the public key ID as well in addition to plain hash fingerprint. > But now we're getting a different hash from > openconnect_get_peer_cert_hash(), and I'm not sure what the user > should be comparing it against, other than asking "is it the same as > last time?" Unless the new fingerprinting scheme is widely used, it > doesn't help authenticate the server when they're connecting for the > first time. Wouldn't it help to get the new key fingerprint using a command of openconnect? > 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. regards, Nikos
