Thanks everyone for clarification on previous queries
Since during the session resumption handshake in either TLS 1.2 or TLS 1.3 the key exchange does not take place, the client side and the server side both resume based on a previously set up session, so the master key is not going to change . Isn't the data sent post resumption handshake vulnerable to replay attacks ? why do we say that the data is vulnerable to replay only with enable-early data in tls 1.3. I think I am confused on some basics here.
I am saying this because if I save the session in a file, the master key gets fixed. I see that during the resumption handshake too, the client hello message has a client_random value which as per my understanding is required for generating the master secret. But the master key is always read from the previous session info saved in the file, hence I am a little confused will the master secret change after every resumption connection.
2) If master secret doesn't change for the resumed connection, shouldn't it change on each handshake finish (full or resumption handshake) for more secure communication?
I think that happens only on full-handshake in ephemeral type ciphers (e.g. ECDHE) but not in RSA type. Am I correct ?
Thanks
BR,
Neetish
On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 18/07/17 22:27, Neetish Pathak wrote:
> Hi ,
> thanks Matt, this is helpful
>
>
> One more query on how I can enable 0.5 RTT data from the server side. It
> is mentioned in TLS 1.3 specification. I thought it can be implemented
> by sending early data from server side after reading the early data.
That is correct, and is as documented on this page:
https://www.openssl.org/docs/manmaster/man3/SSL_write_ early_data.html
> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?
0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.
>From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.
Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
