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

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

Hi Hosnieh,

Please understand that once the early secret for PSK-only mode or the 
main secret for ECDHE-mode is compromised, the system is compromised 
already and no randomness can prevent you in such a case.

Also please understand that not all the keys have to be random. I would 
once again recommend to read Section 1.3 in [0] carefully.

See inline:

On 18.11.25 09:16, H.Rafiee wrote:
>
>>
>> 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.
> I think the name of the key should not matter here :) as long as the 
> main message can be received. it meant as well master secret or main 
> secret. 
I fully disagree. As I said, PSK and Main Secret are two *very 
different* *keys* in the TLS 1.3 key schedule. Main Secret has nothing 
to do with 0-RTT, which was your original concern.
>>> , 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?
>
> Yes, You extract the key from the master secret or main secret with 
> HKDF-Extract function.
>
See my above message.
>
> But the value is not random.
>
It is by design.
>
> That means from the same key it generates the same early secret 
> everytime the system starts the communication with new entities that 
> the same master secret exists or even if the client or server of the 
> communication is restarted.
>
I couldn't parse this. Would you mind rephrasing?
>
> In other word, your earlysecret  ist not random.
>
It is by design!
>
> This is the first security concern which I mentioned, by having that, 
> it is similar to having the master secret.
>
It is by design!
>
> Because the rest of keys are generated by this key.
>
> I explain why it is concert later please then wait :)
>
>
>>> 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.
>>
> For generation of three other keys such as binder_key the function has 
> statric inputs including earlysecret and a startic string.
>
Please use proper terminology from TLS specs. By static string, you are 
referring to "labels", right?
>
> The value of this key is as well not random and not changed
>
This is by design.
>
> client_early-traffic_secret: the value of this key is random because 
> the inputs are random
>
Are you calling state of handshake (i.e., ClientHello message) as random?
>
> early_export_master_secret: although there are some staric string, but 
> there is one random value in the input of the function of HKDF-Expand 
> which makes the value random
>
Same question as above
>
> derivedearlysecret: static string as input plus the early secret which 
> was not random, as a result the output is not random
>
There is no key with the name "derivedearlysecret" in TLS 1.3 specs. Did 
you mean key labelled as "salt1" in [0]? If so, this is by design and 
does not have to be random.
>
> HandshakreSecret: in case of PSK_DHE is used and the input is 
> derivedearlySecret which is not random
>
> in other words, many keys here are not random.
>
This is by design!
>>> 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?
>
> In IT systems that use an HSM, Trusted Zone, or TPM, the main master 
> key is stored in the HSM. The idea is that if the system is 
> compromised (for example, due to a vulnerability in OpenSSL or a TLS 
> library implementation), the master secret will not be exposed or 
> lost. This avoids the need to re‑exchange the master secret with all 
> communication partners.
>
> However, when the early secret is derived deterministically from the 
> master secret (without random input),
>
Early Secret is derived from PSK and not directly from master secret.
>
> the rest of the communication no longer depends on the PSK (master 
> secret).
>
PSK != master secret
>
> The early secret is always available to generate handshake keys (which 
> I will call session keys for simplicity).
>
No, this is not only confusing but also wrong. So please don't use such 
simplicity. If you want TLS WG to help you, you have to use the 
terminology that we have in the key schedule in RFC8446(bis).
>
> If the system or TLS library is compromised, the early secret is lost. 
> It cannot be stored in the HSM, because TLS requires it dynamically 
> for key generation during communication.
>
> In other words, once the system is compromised, the early secret is 
> already exposed. Since this secret is derived in a predictable way 
> from the same master secret, with little randomness, an attacker does 
> not even need access to the master secret itself.
>
Randomness cannot protect a system which is already compromised.
>
>
>>> 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".
>>
> I am refering to the functions such as HKDF-Expand that receives 
> inputs for deriving the key.
>
HKDF-Expand is used several times in the key schedule. So you have to be 
precise which key exactly.
>>> As a result, the session key may not be sufficiently random.
>> Which "session key" exactly?
> handshake secret and and I refer you to above that I listed not 
> randomized and randomized key. 
Randomness in handshake secret comes from shared DH secret (g^xy).
>>> 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.
>
> with the way is early secret always needed, you may be only able to 
> protect the whole TLS libarary in a kind of sandbox but you cannot put 
> it in HSM or Trusted zone because
>
> 1- the whole TLS library cannot run in HSM --> it causes performance 
> problem and delay in communication
>
But you can run the TLS library in Trusted Execution Environment with 
good-enough performance, no?
>
> 2- You will be limited to the resources of HSM which is not usually 
> enough. although, if you have hardware accellerator.
>
> Therefore, by compromised TLS library for any vulnerabilities there, 
> then the attacker has access to this name early secret. That means 
> your protection does not fully protect your key which is in the same 
> level as your master secret and by having that , it is like you have 
> the master secret.
>
Yes, this is by design.

-Usama

>>> 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
>>