CURLOPT_SSLCERT_BLOB is not checked when trying to reuse a connection

[ngg]

CURLOPT_SSLCERT_BLOB was added in 7.71.0
In vtls.c the function Curl_ssl_config_matches does not check it for equality when determining if there is a good connection to re-use.
If there are multiple connections after each other to the same host with different client certificates, the first one will be used.
CURLOPT_SSLCERT was checked in this function (data->clientcert), so I think the blob version should be checked as well.

In my current use-case, I first connect to a server without client certificates and later I switch to using them, and it fails because of this issue.

[ngg]

I just realized that the blob is not part of struct ssl_primary_config, so it cannot be easily checked there, so maybe it can be checked in the ConnectionExists function after each Curl_ssl_config_matches invocation, but in that case I also think it should be checked in Curl_ssl_getsessionid. It might be better to move the blob itself to the primary part.

[bagder]

@gvollant, want to take a look at this?

[ngg]

As a really UGLY workaround, I managed to make this work without modifying curl by providing the certificate chain with CURLOPT_SSLCERT_BLOB and also providing the hash of the certificate to CURLOPT_SSLCERT. This only works because in vtls/openssl.c the CURLOPT_SSLCERT_BLOB takes priority so the file is not used (which is not even existing, as it is only a hash), but the filename is checked in the reuse logic.
I didn't try other SSL backends, and the docs does not explicitly say what happens if both the blob and the file is provided, it might be worth specifying the exact behavior in that strange case.

[dfandrich]

This reminds me of CVE-2016-5420 https://curl.haxx.se/docs/CVE-2016-5420.html

[bagder]

Me too, but since this is a brand new feature in 7.71.0 there shouldn't be any released software having had the chance to get this messed up yet. Possibly this bug is reason enough for a patch release soon?

[ngg]

I'm really sorry for not reporting this privately, I didn't think it has serious security implications, as this doesn't leak any new information to servers (the certificate was already used in a previous connection) and certainly does not leak any private information (which would be the case if this bug happens with passwords for example).

Because this bug is already public (to those checking this Github issue), I think the best way to treat it would be to create a patch release soon to publicly disclose the issue to every potentially affected user. (I don't think there are many software that already uses this feature)

[bagder]

I let had this issue rumble in my head for an hour and I'm now convinced this is reason enough for a patch release. Let's aim at fixing this ASAP and doing a 7.71.1 on Wednesday, July 1st. I'll email the list about it too. We have a few other regressions as well that will be fine to get patched sooner rather than later.

[bagder]

First take at a fix submitted in #5619. Please give it a look.

[gvollant]

I'll look