On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 31/07/17 20:37, Neetish Pathak wrote:
> On 26/07/17 00:05, Neetish Pathak wrote:
> >> *Pseudocode for server*
> >> *
> >> *
> >> tcp_accept
> >> *
> >> *
> >> read_early{
> >>
> >> if(read_early_success){
> >> write_early(data)
> >> }
> >> }
>
> There is a bit of complexity here (covered in the docs), i.e.
> SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
> SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
> but the server may or may not be able to write early data. I assume that
> you have covered that in your actual code and it's just skimmed over
> here in your pseudo code.
>
>
>
> So, I consider read_early_sucess when SSL_read_early_data() returns
> SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> before declaring success. Look at the case checks below
>
> *case* SSL_READ_EARLY_DATA_SUCCESS:
>
> totalBytes += readBytes;
>
> * break*;
>
> *
> *
>
> *case* SSL_READ_EARLY_DATA_FINISH:
>
> totalBytes += readBytes;
>
> * if* (SSL_EARLY_DATA_ACCEPTED ==
> SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>
> readBuf = string(readBuffer);
>
> * return* SUCCESS;
>
> }
>
>
> So, are you suggesting that early data may not be written from the
> server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )
SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
EndOfEarlyData message. Often (but not always - dependent on the
implementation) the client Finished message is also in the same packet
which OpenSSL will immediately try and process. As soon as it has done
so the handshake is complete and it is too late for the server to write
early data. Calls to SSL_write_early_data() by the server at this point
should fail (do you not see this???).
You should write early data on the server side as soon as
SSL_READ_EARLY_DATA_SUCCESS is received.
Yes, this is what I tried and it worked. Thanks for the clarification
> > No. Time Source Destination
> > Protocol Length Info
> > 215 18.381122 ::1 ::1
> > TLSv1.3 762 Application Data
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> > 144, Ack: 3738, Len: 686 -----I don't know why this application data
> > is sent from server. My guess is this is session info
>
> It could be the NewSessionTicket message going from the server to the
> client. But if so that is a little strange. The NST message is only sent
> after the handshake is complete (so no more early data is possible). At
> this point SSL_read_early_data() should have returned
> SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
> and any calls to SSL_write_early_data() will fail.
>
>
> Yes, here the handshake is completed. Will the new session ticket be
> sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> that new session tickets may be sent after server receives Finished from
> the client and it creates a unique association between the ticket value
> and a secret PSK derived from the resumption master secret.
> But looks like, I am receiving new session ticket every-time. So, as per
> the implementation, new session ticket is a must I guess. Am I right?
> When will I not receive new session ticket in TLS 1.3?
The OpenSSL implementation *always* sends a NewSessionTicket message
immediately after the handshake is complete. This is not required, but
is allowed by the spec. Currently there is no way to disable this
behaviour. Do you need/want it (if so, why)?
No, I do not need to disable it per se. The handshake completion at the client side is independent of the newsession ticket coming from the server side if I am correct. So the handshake operation (specifically SSL_connect) will return even if new session ticket has not arrived from the server. I was asking why new session ticket is needed during the resumption handshake. Isn't it just an overhead?
>
> Also, I believe it is different than how new session ticket works in TLS
> 1.2 where it was sent only once to share the encrypted ticket from the
> server side when the client indicates support for session tickets.
Yes, TLSv1.2 session tickets share the same name and have a similar
purpose, but are otherwise *completely* different to TLSv1.3 session
tickets.
Understood
> >
> > No. Time Source Destination
> > Protocol Length Info
> > 217 18.381210 ::1 ::1
> > TLSv1.3 9917 Application Data ----------*Intended
> > Application Data that was intended to be early data *
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> > 830, Ack: 3738, Len: 9841
> >
> > No. Time Source Destination
> > Protocol Length Info
> > 219 18.381308 ::1 ::1
> > TLSv1.3 100 Application Data . ---------Application Data
> > from client (I also see this application data sent everytime, not sure why)
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 3738, Ack: 10671, Len: 24
> >
> >
> > No. Time Source Destination
> > Protocol Length Info
> > 220 18.381309 ::1 ::1
> > TLSv1.3 100 Application Data . ---------Application Data from
> > server (I also see this application data sent everytime, not sure why)
>
> Perhaps these are close_notify alerts? Are you shutting down the
> connection cleanly at this point?
>
>
> I am shutting down the connection from the client side. Server is up all
> the time for any new connection.
As soon as you call SSL_shutdown() then a close_notify alert is sent.
Typically you do that on both the client and the server sides which
seems to match your wireshark trace.
OK Thanks
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
