<div dir="ltr"><div>Thanks everyone for clarification on previous queries</div><div><br></div>1) I had a general query regarding the handshake resumptions. <div>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. </div><div><br></div><div>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.</div><div><br></div><div>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? </div><div>I think that happens only on full-handshake in ephemeral type ciphers (e.g. ECDHE) but not in RSA type. Am I correct ?</div><div><br></div><div><br></div><div><br></div><div>Thanks</div><div>BR,</div><div>Neetish</div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 18/07/17 22:27, Neetish Pathak wrote:<br>
> Hi ,<br>
> thanks Matt, this is helpful<br>
><br>
><br>
> One more query on how I can enable 0.5 RTT data from the server side. It<br>
> is mentioned in TLS 1.3 specification. I thought it can be implemented<br>
> by sending early data  from server side after reading the early data.<br>
<br>
</span>That is correct, and is as documented on this page:<br>
<br>
<a href="https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/<wbr>manmaster/man3/SSL_write_<wbr>early_data.html</a><br>
<span class=""><br>
> But then how can that data be read on the client side since<br>
> read_early_data api is invalid on client side ?<br>
<br>
</span>0.5 RTT data is sent from the server to an unauthenticated client. At<br>
this point in the process the server has sent all of its messages<br>
(including its Certificate/CertificateVerify/<wbr>Finished messages) but it<br>
has not received the Client Finished or any client<br>
Certificate/CertificateVerify if one is going to be sent.<br>
<br>
>From the client's perspective 0.5 RTT data is received *after* it has<br>
processed the server's Certificate/CertificateVerify/<wbr>Finished messages),<br>
and after it has sent its own Finished (and<br>
Certificate/CertificateVerify if appropriate). In other words from the<br>
client's perspective the server is fully authenticated and 0.5 RTT data<br>
is indistinguishable from post-handshake data. Just use SSL_read() as<br>
normal to receive it.<br>
<div class="HOEnZb"><div class="h5"><br>
Matt<br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div></div></div>