TLS 1.3 with PSK Cipher

[Smuul]

Description:

I am attempting to perform a TLS 1.3 handshake using a PSK cipher (TLS_AES_128_GCM_SHA256), and I’m encountering issues where the OpenSSL client sends an "Unexpected Message" alert after the Finished message sent from TLS-Attacker Server.

Scenario:

TLS-Attacker Server Command:

java -jar apps/TLS-Server.jar -port 4433 -config resources/configs/tls13.config -version TLS13 -workflow_trace_type TLS13_PSK

OpenSSL Server Command:

openssl s_client -tls1_3 -connect 127.0.0.1:4433 -psk 316132623363346435653666 -ciphersuites TLS_AES_128_GCM_SHA256 -keylogfile /tmp/.ssl-key.log -msg -debug

tls13.config

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<config>
    <defaultPSKKey>316132623363346435653666</defaultPSKKey>
    <highestProtocolVersion>TLS13</highestProtocolVersion>
    <defaultClientSupportedSignatureAndHashAlgorithms>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_SHA256</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_SHA384</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_SHA512</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>ECDSA_SHA256</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>ECDSA_SHA384</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>ECDSA_SHA512</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA256</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA384</defaultClientSupportedSignatureAndHashAlgorithm>
        <defaultClientSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA512</defaultClientSupportedSignatureAndHashAlgorithm>
    </defaultClientSupportedSignatureAndHashAlgorithms>
    <defaultClientSupportedCipherSuites>
        <defaultClientSupportedCipherSuite>TLS_AES_128_GCM_SHA256</defaultClientSupportedCipherSuite>
        <defaultClientSupportedCipherSuite>TLS_AES_256_GCM_SHA384</defaultClientSupportedCipherSuite>
    </defaultClientSupportedCipherSuites>
    <defaultServerSupportedCipherSuites>
        <defaultServerSupportedCipherSuite>TLS_AES_128_GCM_SHA256</defaultServerSupportedCipherSuite>
        <defaultServerSupportedCipherSuite>TLS_AES_256_GCM_SHA384</defaultServerSupportedCipherSuite>
    </defaultServerSupportedCipherSuites>
    <defaultClientNamedGroups>
        <defaultClientNamedGroup>ECDH_X25519</defaultClientNamedGroup>
    </defaultClientNamedGroups>
    <defaultServerNamedGroups>
        <defaultServerNamedGroup>ECDH_X25519</defaultServerNamedGroup>
    </defaultServerNamedGroups>
    <supportedVersions>
        <supportedVersion>TLS13</supportedVersion>
    </supportedVersions>
    <defaultSelectedNamedGroup>ECDH_X25519</defaultSelectedNamedGroup>
    <defaultClientKeyShareNamedGroups>
        <defaultClientKeyShareNamedGroup>ECDH_X25519</defaultClientKeyShareNamedGroup>
    </defaultClientKeyShareNamedGroups>
    <addECPointFormatExtension>false</addECPointFormatExtension>
    <addEllipticCurveExtension>true</addEllipticCurveExtension>
    <addSignatureAndHashAlgorithmsExtension>true</addSignatureAndHashAlgorithmsExtension>
    <addSupportedVersionsExtension>true</addSupportedVersionsExtension>
    <addKeyShareExtension>true</addKeyShareExtension>
    <addRenegotiationInfoExtension>false</addRenegotiationInfoExtension>
    <defaultSelectedCipherSuite>TLS_AES_128_GCM_SHA256</defaultSelectedCipherSuite>
    <defaultServerSupportedSignatureAndHashAlgorithms>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_SHA256</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_SHA384</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_SHA512</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>ECDSA_SHA256</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>ECDSA_SHA384</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>ECDSA_SHA512</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA256</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA384</defaultServerSupportedSignatureAndHashAlgorithm>
        <defaultServerSupportedSignatureAndHashAlgorithm>RSA_PSS_RSAE_SHA512</defaultServerSupportedSignatureAndHashAlgorithm>
    </defaultServerSupportedSignatureAndHashAlgorithms>
</config>

Observations:

When the TLS-Attacker Server sends the Finished Message the OpenSSL Client sends an UnexpectedMessage Alert

Am I missing something? Any guidance or support would be greatly appreciated. Thank you!

[ic0ns]

I think the issue is that the config you are giving to TLS-Attacker is not properly setup for a PSK connection. TLS-Attacker is built for testing purposes, meaning it will execute exactly what you tell it to do, even if it's against what the specification says you should do. In your case. You configured TLS-Attacker to send the messages of a PSK connection (by setting the workflow_trace_type), but you chose the contents of the messages according to a regular (default) TLS 1.3 connection (by providing the example for TLS 1.3). This results in the ServerHello message not containing the PSK extensions, which causes the client to think (and also TLS-Attacker) that this is not intended to be a PSK connection but a regular one. That is why both parties derive a shared secret as normal, and then the client (rightfully) complains that the TLS-Attacker is sending a Finished message instead of a Certificate message.

[Smuul]

Thanks for your answer!
I'm going to show you what I'm doing now:

TLS-Attacker Server Setup

Added Extensions

• supported_Versions = TLS13
• key_share
• psk_identity

Server Configuration

In the server configuration, I set up a defaultPskSet as follows:

<defaultPskSets>
        <defaultPskSet>
            <preSharedKeyIdentity>333333303333333133333330</preSharedKeyIdentity>
            <preSharedKey>316132623363346435653666</preSharedKey>
        </defaultPskSet>
</defaultPskSets>

Encountered Error

While running the configuration, I encountered the following error:

This issue occurred due to the line:
pskIdentity.getIdentity().getValue()))

from

The pskIdentity was not being properly set, leading to a null value for the identity.

Fix

To resolve this issue, I modified the copyPskSets method in PreSharedKeyExtensionMessage.java by adding:
pskIdentity.setIdentity(pskSets.get(x).getPreSharedKeyIdentity());

This ensures the identity value is correctly copied.

TLS-Attacker Client Setup

Added Extensions

• supported_Versions = TLS13
• key_share
• psk_identity
• psk_key_exchange_modes

OpenSSL Server Configuration

openssl s_server -tls1_3 -accept 4432 -nocert -psk 316132623363346435653666 -psk_identity client-identity -ciphersuites TLS_AES_128_GCM_SHA256

Encountered Error

I’m unsure whether the modifications I made to make it work were truly necessary or if I’m still missing something. Additionally, regarding the TLS-Attacker Client case, I’m not entirely certain what is wrong. I’d greatly appreciate it if you could help clarify these doubts.

[hamma96]

Hi, I was trying to do the same to run client using TLS-Attacker against openssl server (TLS1.3) and I failed to have a full handshake
I am getting this error:

and when I checked the trace:

did someone face this problem in the past?

[Smuul]

I attempted the same setup, but instead of using an OpenSSL server, I used a TLS-Attacker server. This time, the handshake completed successfully. However, when I analyzed the trace in Wireshark and tried to decrypt it, the decryption failed. I'm only able to see the encrypted messages as Application Data.

Interestingly, upon reviewing the logs, it appears that TLS-Attacker is successfully decrypting the received messages. Here is an example from the logs:

This raises the question:

• Could this behavior be due to a bug in Wireshark?

• Or am I possibly using an incorrect Pre-Shared Key (PSK) or decryption parameters in Wireshark?

Any insights would be appreciated.