--servercert option is insecure

Ryan Taylor rptaylor at uvic.ca
Wed May 9 18:38:15 PDT 2018


Hello,

The manual describes the --servercert option as follows:
http://www.infradead.org/openconnect/manual.html

"Accept server’s SSL certificate only if the provided fingerprint matches. The allowed fingerprint
types are SHA1, and SHA256. They are distinguished by the ’sha1:’ or ’sha256:’ prefixes to the hex
encoded hash. To ease certain testing use-cases, a partial match of the hash will also be accepted,
if it is at least 4 characters."

Is it really true that only 4 characters need to match the hash in order for the certificate to be
accepted?

If my calculations are correct, the probability of any randomly-generated certificate matching at
least 4 characters of another certificate is about 5.5% (see below). Therefore, an attacker
targeting a VPN service would need to randomly generate only 19 certificates on average (which is
trivial) in order to get one that can be used to impersonate that VPN service in a MITM attack.
If any clients are connecting using the --servercert option, they will be tricked into accepting
the attacker's certificate as genuine, since 4 characters of the SHA256 hash match.

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?


Thanks,
-rt

P.S.

Probability of a random 4-char hex string matching a given 64-char hex string is (ignoring the
possibility of consecutive repeated characters):  1 - (1 - 16^-4)^61 = 0.00093

A random 64-char string has 61 attempts to match a 4-char substring, so the probability is
(ignoring the possibility of consecutive repeated characters):  1 - (1 - 0.00093)^61 = 0.055



-- 
Ryan Taylor
Research Computing Specialist
Research Computing Services, University Systems, University of Victoria


More information about the openconnect-devel mailing list