--servercert option is insecure
Nikos Mavrogiannopoulos
n.mavrogiannopoulos at gmail.com
Thu May 10 11:26:30 PDT 2018
On Thu, May 10, 2018 at 1:26 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Thu, 2018-05-10 at 01:38 +0000, Ryan Taylor wrote:
>>
>> If this is correct, using the servercert option is a significant security problem.
>>
>> Perhaps the servercert option is not intended to be used for any sort of security guarantee
>> whatsoever. However if that is the case, there should probably be a warning in the man page, and
>> also printed on standard output, kind of like overriding a web browser to connect to a site with an
>> untrusted certificate. Users who have not done the math or read the man page carefully may be using
>> this option with the mistaken belief that it provides some security assurance via a sort of
>> makeshift certificate pinning.
>>
>> Or, this could be fixed by requiring a complete match of the hash instead of just 4 characters.
>> What are the "certain testing use-cases" and how important are they compared to the security
>> considerations?
>
> Hi Ryan, thanks for looking at this.
>
> As Dan says, if a user provides a truncated hash then we do require the
> match to be at the beginning of the hash. It's not just *any*
> substring. Even so, yes: 4 characters isn't many, so there's a fair
> chance of a false match. Ultimately, Don't Do That Then.
>
> I'm happy to improve the documentation to make it clear that there is
> absolutely no excuse for a user to use anything less than the full hash
> in "production" use, or indeed in any circumstance where cut-and-paste
> works.
>
> I vaguely recall that I had similar reservations when this feature was
> first added (Nikos, was it you?). But I *have* found it useful
> occasionally in testing, in strange setups where I haven't been able to
> cut and paste for some reason. At the time, we were forcibly removing
> the "--no-cert-check" option because I threw my toys out of the pram
> after finding people advocating its use in production — so even a 4-
> char match was better than that! :)
Yes it was me :) The small substring match helps when running
openconnect in a VM without copy+paste or similar setups. There is
indeed no excuse to try to save some bytes on production. Btw. we also
have the more standard pin-sha256 pinning which reduces typing even
less (doesn't seem to be in a released version)
regards,
Nikos
More information about the openconnect-devel
mailing list