[TLS] Re: Security Concern in TLS 1.3 and OpenSSL Implementation

[Muhammad Usama Sardar <[e-mail]>]

Hello Hosnieh,

I am not an OpenSSL expert (and it may be the case that the key names 
used there are a source of confusion) but from specification 
perspective, I find your explanation of keys very confusing. Also, I am 
not sure what kind of /randomness/ you are looking for. Please see inline:

On 17.11.25 17:40, H.Rafiee wrote:
> In short, TLS 1.3 uses 0-RTT to improve performance. To achieve this, it derives a key from the pre-shared key (PSK or master key)
I am not sure why you call it "master key". Such a key name does not 
exist in TLS 1.3 specs (neither RFC8446 nor RFC8446bis). There was 
"Master secret" in RFC8446 which is now "Main secret" in RFC8446bis but 
that's a completely different key compared to PSK. And "Main secret" is 
generated very late in the key schedule, which seems irrelevant to your 
explanation.
> , called the early secret (in OpenSSL). This early secret is derived in a very simple way
What do you mean by "very simple way"? What in addition to HKDF-Extract 
were you expecting to generate Early Secret from PSK?
> and is used for encrypting and authenticating the first communications.

That's actually not correct. Early Secret itself is never used except 
for generating three other keys via application of Derive-Secret in the 
first stage of derivation. One of those three keys is 
client_early_traffic_secret, which is then used to generate 
client_write_key via application of HKDF-Expand-Label in the second 
stage of derivation. client_write_key is the one used for encrypting 
0-RTT data.

> The main concern is that this early secret is neither randomized nor changed after system startup.
This is because the assumption is that PSK remains secret. Could you 
please clarify what do you mean by "system startup"? Are you resuming 
connections multiple times with the same PSK?
> For subsequent session keys, a static value is also used as input to the session key generation function, along with a few random values.

I am a bit lost in your terminology here. Which "static value"? Are you 
referring to the /label/ inputs for Derive-Secret?

Which "few random values"? Are you referring to the state of the 
handshake used as input in Derive-Secret? If so, there is nothing more 
than ClientHello available at the time when this key is generated, so I 
am not sure how one can add more "randomness".

> As a result, the session key may not be sufficiently random.
Which "session key" exactly?
> Questions to the community:
>
> Is this an OpenSSL implementation issue, or a protocol-level security problem?
> Were there any tests conducted for the protocol before its release?
> Is this issue already known?
I don't think it's an issue but I may be missing something. Please 
provide answers to my questions.
> Security risks:
> If there is a bug in the system or the early secret is not well protected in memory (it cannot be stored in an HSM or trusted environment because it needs to be readily available to TLS library), an attacker could reproduce or decrypt communication in case of vulnerabilities in one of the communicating systems.
Sure, if Early Secret is not protected, there is nothing preventing 
0-RTT data. That is by design.
> Even if the TLS library uses isolated memory space, any bug in OpenSSL could expose the secret.
Same applies here.
> Since the early secret lacks sufficient randomness, it seems necessary to change the PSK to prevent attackers from establishing secure communication.

Again, please clarify "randomness". Where would that random value be 
stored? Imagine somehow the randomness is there, if attacker has access 
to memory, can't it get that random value too?

> Generally speaking, the role of the PSK is weak here. Even if it is well protected, as long as the early secret is poorly protected, knowing the early secret compromises the entire system.

Yes, that is by design. PSK-only does not have the same properties as 
the full handshake with ECDHE. In particular, losing Early Secret in 
PSK-only breaks all guarantees for 0-RTT data.

In general, you may find Section 1.3 in [0] helpful for general 
understanding of TLS key schedule.

-Usama

[0] 
https://www.researchgate.net/publication/396245726_Perspicuity_of_Attestation_Mechanisms_in_Confidential_Computing_Validation_of_TLS_13_Key_Schedule