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 -- [email protected]
To unsubscribe send an email to [email protected]
