Fix Client Certificate Verification when Using Extended Master Secret #143
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently it is not possible for UTLS clients to connect to OpenSSL servers (and probably any RFC compliant server) when performing mutual TLS authentication and using the extended master secret extension (and using TLSv1.2)
The session hash used in extended master secret does not include the CertificateVerify handshake message. see: https://www.rfc-editor.org/rfc/rfc7627#section-3
Note: It should be possible to calculate the master secret on both the client and the server after the client has sent the ClientKeyExchange message. If the CertificateVerify message was part of the hash then this would not be possible on the server. This is also how openssl implements extended master secret. For example you can see from the control flow in openssl that the client key exchange message triggers generating the master key: