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

[Thom Wiggers <[e-mail]>]

Dear Hosnieh,

TLS is not intended to be secure if the main secret is compromised. Neither are PSK-initiated exchanges secure if the exported PSK is compromised. If you are not using PSK with ephemeral key exchange (PSK-ECDHE), there is no forward secrecy. 0-RTT data does not enjoy forward secrecy either.

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

There should be no entities with the same Main Secret. Main Secrets are unique to TLS connections and derived from the key schedule (usually from ECDHE or KEM key exchange). Main Secrets are not intended to be extracted from the TLS state machine. They have no user value. HSMs or TEE should not be involved with them. 

If you are using PSK handshakes without ECDH there is no security against PSK compromise. All keys in a PSK-without-ECDHE handshake are deterministic, this is well understood and documented. 

This is A) why almost nobody seems to support/use PSK-only handshakes and B) e.g. TLS session tickets are often one-time-use.

Regards,

Thom Wiggers



> Op 18 nov 2025, om 17:16 heeft H.Rafiee <[e-mail]> het volgende geschreven:
> 
> Hi Usama,
> 
> thanks for your explanation. please find mine inline.
> 
> Best Regards,
> 
> Hosnieh
> 
> On 11/17/25 7:01 PM, Muhammad Usama Sardar wrote:
>> 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.
> 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.
>> 
>>> , 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.  But the value is not random. 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.
> 
> In other word, your earlysecret  ist not random. This is the first security concern which I mentioned, by having that, it is similar to having the master secret. 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. The value of this key is as well not random and not changed
> 
> client_early-traffic_secret: the value of this key is random because the inputs are 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
> 
> derivedearlysecret: static string as input plus the early secret which was not random, as a result the output is not 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. 
> 
>>> 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), the rest of the communication no longer depends on the PSK (master secret). The early secret is always available to generate handshake keys (which I will call session keys for simplicity). 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.
> 
> 
> 
>>> 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.
> 
>>> 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.
>> 
>>> 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
> 
> 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.
> 
>>> 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
>> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]