Server certificate hash checking

[Kevin Cernekee]

On Wed, Dec 31, 2014 at 8:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
>> I think it will be confusing to use a different ID for the software to
>> detect a changed certificate and another for a human.
>
> No. The human is never involved in the check for a changed certificate.
> The human is only ever asked if *this* certificate, right now, is the
> current certificate they expect from the server.
>
> They are different things, and one is fairly much transparent to the user
> anyway.
>
> To be honest though, there's a limit to how much I can bring myself to
> care about this use case. By the time we're presenting a cert to the user
> in *any* form for manual acceptance, 99% of the time the game is already
> lost. The user is just going to click "yes" without doing any check at
> all. If you want security you *need* to install the CA and make the cert
> validate properly.

For Cisco AnyConnect, the rate is probably 99%+.  In fact, there are
official Cisco AnyConnect Linux releases in the wild that show a cert
warning on legitimate CA-issued certs, and break if you tell it to
"always accept" that cert.  So some users are happily clicking
"proceed anyway" on every single connection.

But the more sophisticated users who went out of their way to install
the lesser-known open source alternative, especially the CLI versions,
are more likely to verify cert mismatches.  Or at least to notice if
the client tells them the hash unexpectedly changed from last time.

One thing that might help here is for frontends like luci-ocserv to
report the expected cert fingerprint in a prominent location, and warn
the user against accepting any new certs if they didn't change the
ocserv configuration.  If this page can be viewed in read-only mode
without logging in to the router, that is even better.