--servercert option is insecure

[Ryan Taylor]

Hi,

> No, openconnect checks for a matching *prefix*, not for a match to a substring at an arbitrary position. 

Okay, so if only 4 characters are used, that changes the probability of a random match to 1/16^4.
An attacker would need to generate on average 16^4 certificates, which could be done on a typical desktop computer in perhaps about 15 minutes based on a simple estimate.

However, if I understand correctly what you are saying, when a user provides N characters with the servercert option (where N >= 4), all N characters must match in order for the connection to succeed. I did not realize that and it is not what a literal reading of the documentation implies, but some testing appears to confirm that this is the case. That more or less eliminates the security concern: users can be as secure (or not) as they like by choosing the number of hash characters to specify.

> 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.

A helpful clarification could be to replace the sentence 
"To ease certain testing use-cases, a partial match of the hash will also be accepted, if it  is at least 4 characters."

with something like this:

"The provided string must contain at least 4 hash characters, and all provided characters must match the hash of the server's certificate, starting from the beginning. Using a string shorter than the complete certificate hash reduces security and should only be done for testing purposes."



As a side note, there is another point of confusion here. This documentation on the servercert option refers to fingerprints, but strictly speaking, openconnect is not using certificate fingerprints. It is using the "public key ID" instead, and incorrectly referring to it as the fingerprint.  I admit I am not sure what the difference is between the fingerprint and public key ID, but evidently there is a difference. You can see this as follows.  Invoke openconnect without the servercert option, and use the option to view the certificate:

Certificate from VPN server "vpn.example.org" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert sha256:1aaa......
Enter 'yes' to accept, 'no' to abort; anything else to view: view
...
Other Information:
	Fingerprint:
		sha1:642b...
		sha256:5807...
	Public Key ID:
		sha1:9087...
		sha256:1aaa...

The hash that openconnect prompts you to use with the servercert option is the "public key ID" hash ("1aaa..." in this example), not the fingerprint.

This can cause confusion and perhaps alarm or suspicion, because if you try to verify the fingerprint with openssl or with a web browser, it shows the real fingerprint, which is a different value ("5807..." in this example).

openssl s_client -showcerts -servername vpn.example.org -connect vpn.example.org:443 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -inform pem


(Side side note: the reason this came up in the first place is that our certificate is not being recognized by openconnect, despite (as far as I can tell) being signed by a CA that is included in the trust store of the OS, and being accepted by firefox.)

Thanks,
-rt

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

________________________________________
From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
Sent: May 10, 2018 11:26 AM
To: David Woodhouse
Cc: Ryan Taylor; openconnect-devel at lists.infradead.org
Subject: Re: --servercert option is insecure

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