On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <m...@openssl.org> 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

Reply via email to