Extend tlsfuzzer coverage

[Jakuje]

Description

This mostly extends the test coverage for TLS 1.2 and ECDSA and EdDSA keys. I did not touch the RSA-PSS coverage, as it needs to use the special RSA-PSS keys and certificates to work correctly and pkcs11-provider can not use them. This will likely be handled in some follow-up PR.

Checklist

• Test suite updated with functionality tests
• Test suite updated with negative tests

Reviewer's checklist:

• Any issues marked for closing are addressed
• There is a test suite reasonably covering new functionality or modifications
• This feature/change has adequate documentation added
• Code conform to coding style that today cannot yet be enforced via the check style test
• Commits have short titles and sensible commit messages
• Coverity Scan has run if needed (code PR) and no new defects were found

[simo5]

LGTM!

Covscan not needed.

[tomato42]

there are multiple scripts missing compared to instructions from openssl/openssl#25724

also, I think it would be nice to check that PKCS#11 can be used to delegate verification of signatures too...?

[Jakuje]

also, I think it would be nice to check that PKCS#11 can be used to delegate verification of signatures too...?

AFAIK this is implicitly tested by adding the propquery to the openssl cli in the second invocation of the tests:

https://github.com/latchset/pkcs11-provider/blob/6be8f7aedc119d5ceb7b9e4db5c4df8b73ee46af/tests/ttlsfuzzer#L81C1-L81C6

This should force the OpenSSL to import even public keys to the pkcs11 provider and do the operations on them. This already caught us some architectural issues in the past that have been fixed.

[Jakuje]

there are multiple scripts missing compared to instructions from openssl/openssl#25724

For RSA, I added test-dhe-rsa-key-exchange-signatures.py, but again, the SHA1 signatures are failing per default c-p so I can add that, but will have to skip these:

test-dhe-rsa-key-exchange-signatures.py:stdout: 'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 sha1 signature'
test-dhe-rsa-key-exchange-signatures.py:stdout: 'TLS_DHE_RSA_WITH_AES_128_CBC_SHA sha1 signature'
test-dhe-rsa-key-exchange-signatures.py:stdout: 'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 sha1 signature'
test-dhe-rsa-key-exchange-signatures.py:stdout: 'TLS_DHE_RSA_WITH_AES_256_CBC_SHA sha1 signature'

The test test-signature-algorithms.py again talks about SHA-1 signatures. Is there any point in keeping it or ok to skip altogether?

[tomato42]

The test test-signature-algorithms.py again talks about SHA-1 signatures. Is there any point in keeping it or ok to skip altogether?

if there are other cases that do pass, yes, modifying it with -x ... -X ... to expect failures is completely valid way to use those scripts

[tomato42]

also, I think it would be nice to check that PKCS#11 can be used to delegate verification of signatures too...?

AFAIK this is implicitly tested by adding the propquery to the openssl cli in the second invocation of the tests:

https://github.com/latchset/pkcs11-provider/blob/6be8f7aedc119d5ceb7b9e4db5c4df8b73ee46af/tests/ttlsfuzzer#L81C1-L81C6

This should force the OpenSSL to import even public keys to the pkcs11 provider and do the operations on them. This already caught us some architectural issues in the past that have been fixed.

ok, but isn't the point of those tests to ensure end-to-end support for that, in the TLS context specifically?

[simo5]

LGTM