New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certificate verification fails with RSAE-PSS, SHA512 and a 1024-bit RSA key. #16167
Comments
Trying to reproduce with just openssl:
The client doesn't even try.
The 1024-bit key works with RSA-PSS+SHA384, and the 2048-bit key works with RSA-PSS+SHA512. |
The RSA PSS code does this: So unless this particular case was special cased to pass in either sLen = RSA_PSS_SALTLEN_MAX or (sLen = RSA_size(rsa) - hashLen - 2) it will not work. |
Hm, RFC8446 §4.2.3 says:
So I think truncating to 62 bytes is wrong. Instead of filing this ticket against OpenSSL, I should be filing one against GnuTLS for the fact that this does work there. (https://gitlab.com/gnutls/gnutls/-/issues/1258). And fixing my own code not to truncate either. (https://gitlab.com/openconnect/openconnect/-/commit/6c2266deb189a55a00be8a8f8448d879c3faff6a). There is perhaps an argument that the client shouldn't have tried TLSv1.3 in this case. This one works:
And this one doesn't:
Admittedly that's a bit of a contrived test, but |
RFC8446 forbids this, and it looks like it was a bug that it ever worked against GnuTLS. • https://gitlab.com/gnutls/gnutls/-/issues/1258 • openssl/openssl#16167 Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This is a duplicate of a closed issue that was discussed by the OTC previously. See #12713 |
When RSA-PSS is used with a 1024-bit RSA key and SHA512, the salt length ends up being 62 bytes.
However, we end up calling
RSA_verify_PKCS1_PSS_mgf1()
with thesLen
argument set to-1
which means it expects the salt length to be exactly the hash length. Thus it complains:The client in this case is OpenConnect, and because all crypto libraries hate their users I actually had to write my own PSS padding in order to get keys from a TPM to work with TLSv1.3: https://gitlab.com/openconnect/openconnect/-/commit/ff367965fcc13f6c1ba7fbda7a49d1467f1b39de
This client does authenticate to
gnutls-serv
using TLSv1.3 and RSA-PSS-RSAE-SHA512.I had to hack my client to pretend the key doesn't support SHA256 or SHA384 in order to force SHA512.
The text was updated successfully, but these errors were encountered: