Handling of servers CERTIFICATE REQUEST

[boaks]

When a server request a client certificate, the TLS-Client seems to ignore this and so the handshake fails. The cause seems to be the client, which doesn't include a certificate message.

Is this intended? Or must I use additional parameters? I tried to load the certificate from a java keystore, but that doesn't change the behavior.
At least I would expect, that according Client Certificate

If no suitable certificate is available, the client MUST send a certificate message containing no certificates

such a certificate message with an empty list is send.

I use the current master of TLS-ATTACKER and OpenSSL 1.1.1 11 Sep 2018.
Steps to reproduce:

openssl s_server -key rsa1024key.pem -cert rsa1024cert.pem -verify 10

java -jar TLS-Client.jar -connect localhost:4433 -version TLS1

Resulting capture:
cert_req_failing.zip

[ic0ns]

Hey,
this is actually intended behavior. TLS-Attacker uses the concept of WorkflowTraces. A WorkflowTrace is a static list of Actions TLS-Attacker will execute. The default workflowTrace in the TLS-Client is a basic handshake based on the default selected ciphersuite. TLS-Attacker will execute these defined actions mercilessly without adjusting them in response to the server behavior. This is done to specifically analyze server behavior based on invalid inputs.

If you want to play with client authentication you can either change the configuration of TLS-Attacker to use client authentication by default, or specify a custom WorkflowTrace to send the appropriate messages. For the config case there is already an example included in the resource folder.
Here are examples on how to do both:
java -jar apps/TLS-Client.jar -connect localhost:4433 -config resources/configs/rsa_clientAuthentication.config
or with a custom workflowTrace like this:

    <Send>
        <messages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </messages>
    </Send>
    <Receive>
        <expectedMessages>
            <ServerHello/>
            <Certificate/>
            <CertificateRequest/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    <Send>
        <messages>
            <Certificate/>
            <RSAClientKeyExchange/>
            <CertificateVerify/>
            <ChangeCipherSpec/>
            <Finished/>
        </messages>
    </Send>
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

and executing:

java -jar apps/TLS-Client.jar -connect localhost:4433 -workflow_input workflow.xml

Cheers
Robert

[boaks]

Thanks a lot!
I already got the feeling, that the implementation is more a skeleton for such configurations.