Bug 65461 - WrappedX509KeyManager ignores key types
Summary: WrappedX509KeyManager ignores key types
Status: NEW
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 5.4.1
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: JMETER_5.5
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-21 17:01 UTC by Pawel Veselov
Modified: 2021-07-23 15:27 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Veselov 2021-07-21 17:01:00 UTC
I've ran into this problem trying to test HTTPS client-server communication protected with Ed25519 keys that uses client-side SSL authentication.

I've wired BouncyCastle as the JSSE provider and the TLS handshake fails with "Invalid algorithm: {sha256(4),ecdsa(3)}". The best explanation on the subject that I found is here: https://github.com/bcgit/bc-java/issues/916

I've traced the problem to JsseSSLManager.WrappedX509KeyManager class. When the JSSE looks for the matching keys, it is being misled by this custom key manager, as:

1) getClientAliases() ignores the key type all together, so it will return aliases for the wrong key key type
2) chooseClientAlias() also ignores the passed in key types, and will return an alias that doesn't match the key type of the actual key that would be returned when requested.

For reasons unknown, the server offers to authenticate the client with two key types - EC and Ed25519, in that order. JMeter ends up returning an Ed25519 key back to JSSE that asked for the EC key, causing a break down in attempting to use the key for any reasons.
Comment 1 Pawel Veselov 2021-07-21 17:01:07 UTC
I think the fix is rather trivial, and I'll file a PR on GitHub once I've tested that things work with a multi-aliased key store.
Comment 2 Pawel Veselov 2021-07-23 15:27:00 UTC
Pull request: https://github.com/apache/jmeter/pull/669