On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
Apologies for the delayed response - I've been away on holiday. Comments
inserted below.
No problem thanks for the replies
Matt
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 )
>> 2) Why does the server not send data (for early write) after the
>> server Hello(and other encrypted message) message even when
>> early_write succeeds on server side. Why does server wait to
>> finish the handshake. I know it waits because I see client sending
>> encrypted messages after server hello message before my intended
>> application data gets sent from server. These encrypted messages
>> from the client side are the usual messages from the client side
>> for handshake completion.
>>
>
> From a quick look through the state machine code, this is supposed
> to work. But someone would probably have to instrument the code
> (e.g., with printf) to tell why the delay is being introduced. I
> don't think I have the availability to do so in the near future, myself.
>
>
>
> I see that the application data is not being sent from server to an
> unauthenticated client. The server is sending data only after receiving
> some encrypted message which I believe is the EndOfEarlyData and
> Finished messages. Following is a dump of wireshark logs for the
> communication with early data enabled. I also tried with some logs in
> Openssl libraries, I see early data gets written from server side when
> write_early_data is called. Internally SSL_write_ex is called which
> completes write and handshake. But I am not sure why application data is
> not actually pushed from the server side. It is waiting for the Client
> finished message.
> I have disabled Nagle's algo during this operation.
Can you confirm whether you have disabled Nagle's algo on both the
client *and* the server?`
Nagle's algorithm is disabled on both the client and the server side.
>
> Client port is 56806 and server port is 12345
>
>
> No. Time Source Destination
> Protocol Length Info
> 207 18.380298 ::1 ::1
> TLSv1.3 956 Client Hello ----------------- Client Hello
>
>
> No. Time Source Destination
> Protocol Length Info
> 208 18.380335 ::1 ::1
> TLSv1.3 2849 Application Data ------------------*Early Data
> from the client side (Intended Application Data)*
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 881, Ack: 1, Len: 2773
>
> No. Time Source Destination
> Protocol Length Info
> 211 18.380624 ::1 ::1
> TLSv1.3 219 Server Hello, Application Data, Application Data .
> ------------Server Hello and (encrypted handshake message/extensions)
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> Ack: 3654, Len: 143
>
> No. Time Source Destination
> Protocol Length Info
> 213 18.380819 ::1 ::1
> TLSv1.3 160 Application Data, Application Data ------Encrypted
> handshake msg from client (*I believe they are end early data and finished*)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3654, Ack: 144, Len: 84
>
>
> 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?
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.
>
>
> 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.
Thanks
Neetish
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
