> So, I finally got around to integrating the new library on the Android > side, and I was wondering how you envisioned the UI working. Well, I give you the DER and you can do whatever the hell you like with it :) The openconnect_get_peer_cert_details() function is just a helper in case you want it. > 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. > > On Android I intentionally did not add a "View Certificate" button as > it is trivial to make a spoofed cert that has authentic data in all of > the human-readable fields. Allowing the user to assess risk based on > that content creates a false sense of security. So they are forced to > use the hash to make a decision. > > 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. > > 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 seems to make sense. In fact openconnect_sha1() is already exported, albeit under OPENCONNECT_PRIVATE, and you could just pass the DER to it. I have no real objection to exporting it properly, or adding an openconnect_get_peer_cert_sha1() again for this purpose. We should probably also ensure the sha1 is included in the openconnect_get_peer_cert_hash() output. Nikos, what do you think? -- dwmw2
