On Thu, May 10, 2018 at 1:26 PM, David Woodhouse <dw...@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 _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
