Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Tue, Aug 1, 2017 at 10:46 AM, Neetish Pathak  wrote:

>
>
> On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell  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.
> Also, this point is not very clear from the man page on when the write
> early data be sent from the server side (after SUCCESS or FINISH). Can it
> be included?
>
>>
>>
>>
>> > > No. Time   SourceDestination
>> > > Protocol Length Info
>> > > 215 18.381122  ::1   ::1
>> > > TLSv1.3  762Application 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 

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell  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   SourceDestination
> > > Protocol Length Info
> > > 215 18.381122  ::1   ::1
> > > TLSv1.3  762Application 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   

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

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.



> > No. Time   SourceDestination
> > Protocol Length Info
> > 215 18.381122  ::1   ::1
> > TLSv1.3  762Application 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)?

> 
> 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.


> >
> > No. Time   SourceDestination
> > 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   SourceDestination
> > Protocol Length Info
> > 219 18.381308  ::1   ::1
> > TLSv1.3  100Application 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:
>

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell  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   SourceDestination
> > Protocol Length Info
> > 207 18.380298  ::1   ::1
> > TLSv1.3  956Client Hello  - Client
> Hello
> >
> >
> > No. Time   SourceDestination
> > 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   SourceDestination
> > Protocol Length Info
> > 211 18.380624  ::1   ::1
> > TLSv1.3  219Server 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   SourceDestination
> > Protocol Length Info
> > 213 18.380819  ::1   ::1
> > TLSv1.3  160Application 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   SourceDestination
> > Protocol Length Info
> > 215 18.381122  ::1

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

On 31/07/17 17:43, Matt Caswell wrote:
> 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,

I meant to say SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_FINISH.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

Apologies for the delayed response - I've been away on holiday. Comments
inserted below.

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.


>> 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?`


> 
> Client port is 56806 and server port is 12345
> 
> 
> No. Time   SourceDestination  
> Protocol Length Info
> 207 18.380298  ::1   ::1  
> TLSv1.3  956Client Hello  - Client Hello
> 
> 
> No. Time   SourceDestination  
> 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   SourceDestination  
> Protocol Length Info
> 211 18.380624  ::1   ::1  
> TLSv1.3  219Server 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   SourceDestination  
> Protocol Length Info
> 213 18.380819  ::1   ::1  
> TLSv1.3  160Application 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   SourceDestination  
> Protocol Length Info
> 215 18.381122  ::1   ::1  
> TLSv1.3  762Application 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.



> 
> 
> No. Time   SourceDestination  
> 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, 

Re: [openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users]

On 07/25/2017 06:05 PM, Neetish Pathak wrote:
>
>
> Please provide any comments if you have or how I should go about
> debugging it. Correct me if I am doing it wrong
>

I don't really have any good suggestions for debugging it.  It might be
interesting to run in a debugger and collect full backtraces on each
entry to ssl3_write_pending() on the server.

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

Thanks Ben for your reply

On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk  wrote:

> [Matt's reply is likely to be high latency]
>
>
> On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  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
>> 
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side just
> after the early_read data. But when I see the wire-shark logs, I see that
> the server data is sent only once the complete handshake has taken place.
> (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as per
> understanding developed from previous discussions
>
> *Pseudocode for client*
>
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>   ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
>
> tcp_accept
>
> read_early{
>
>  if(read_early_success){
>   write_early(data)
>   }
> }
>
> ssl_accept
>
> if(read_early_fail){
> ssl_read
> ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>
>
> Maybe I misunderstand the question, but isn't this is just a natural
> consequence of the server (mis)behavior in (2)?
>


Yes, this is right, the server misbehavior is causing this.


>
>
> 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.

Client port is 56806 and server port is 12345


No. Time   SourceDestination   Protocol
Length Info
207 18.380298  ::1   ::1   TLSv1.3
 956Client Hello   - Client Hello


No. Time   SourceDestination   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   SourceDestination   Protocol
Length Info
211 18.380624  ::1   ::1   TLSv1.3
 219Server 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. 

Re: [openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users]

[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  > 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
> 
> 
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side
> just after the early_read data. But when I see the wire-shark logs, I
> see that the server data is sent only once the complete handshake has
> taken place. (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as
> per understanding developed from previous discussions
>
> *Pseudocode for client*
> *
> *
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>   ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
> *
> *
> tcp_accept
> *
> *
> read_early{
>
>  if(read_early_success){
>   write_early(data)
>   }
> }
>
> ssl_accept
>
> if(read_early_fail){
> ssl_read
> ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>

Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?

> 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.

> 3) Also, the performance of TLS 1.3 using early data or resumption is
> worse than TLS 1.2 resumption on LAN. I see on wire-shark that
> encrypted messages get exchanged in TLS 1.3 during handshake which are
> plaintext in TLS 1.2. I think that causes extra latency. So can we say
> that TLS 1.3 resumption is not recommended for LAN for performance
> enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS
> 1.3 resumption at par with TLS 1.2 resumption and full handshake
> better for TLS 1.3.
>

It seems like it hasn't really sunk in for you that TLS 1.3 is a
seriously different protocol than TLS 1.2, and it provides stronger
security properties, remediating weaknesses of TLS 1.2.  So no, we
should not recommend TLS 1.2 resumption on the LAN -- we should
recommend the more secure option!  If you continue to believe that
latency trumps everything else, you could experiment with
SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric
crypto, though it looks like you'd want to patch
ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I
don't see a way to configure the server to prefer the non-DHE PSK key
exchange.

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  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



Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just
after the early_read data. But when I see the wire-shark logs, I see that
the server data is sent only once the complete handshake has taken place.
(which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per
understanding developed from previous discussions

*Pseudocode for client*

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
  ssl_write(data)
}

ssl_read


*Pseudocode for server*

tcp_accept

read_early{

 if(read_early_success){
  write_early(data)
  }
}

ssl_accept

if(read_early_fail){
ssl_read
ssl_write(data)
}


I am measuring latency on the *client side* from TCP connection start  till
it completes the read (ssl_read returns) (analogues to making a request
from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early
write and then later ssl_read compared to when I execute normal write/read
on the client side

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.

3) Also, the performance of TLS 1.3 using early data or resumption is worse
than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages
get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I
think that causes extra latency. So can we say that TLS 1.3 resumption is
not recommended for LAN for performance enhancement when compared with TLS
1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2
resumption and full handshake better for TLS 1.3.

Thanks
Best regards,
Neetish












> > 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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

Thanks everyone for clarification on previous queries

1) I had a general query regarding the handshake resumptions.
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  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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Viktor Dukhovni]

On Mon, Jul 17, 2017 at 09:54:39AM +0100, Matt Caswell wrote:

>In the default case a server will just use the
> internal session cache. You can populate that cache manually using
> SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
> objects (perhaps loaded from a file) you can manually populate that
> cache at application startup.

When server side (non-ticket) caches are enabled in Postfix it uses
a file-based key-value store.  The lookup key is the session id
sent by the client, and the value is the serialized session object.

So it is also possible to load saved sessions on demand.  In Postfix
this is used to share sessions within a pool of cooperating processes,
and the cache is deleted on restart, but that's a design choice
that other applications could (with care) make differently.  I
would avoid using session objects across changes in the OpenSSL
library version between the process that saved the session and the
process that's reading it.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Mon, Jul 17, 2017 at 1:54 AM, Matt Caswell  wrote:

>
>
> On 14/07/17 20:18, Neetish Pathak wrote:
> >
> >
> > On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 13/07/17 23:52, Neetish Pathak wrote:
> > > Hi All,
> > > Help with these queries please,
> > >
> > > 1) Is it possible to use external session files (with session info
> as
> > > identifiers or tickets for out of band resumption) for session
> > > resumption in TLS 1.2. Does it need some kind of callback like the
> way
> > > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> > > SSL_set_psk_use_session_callback
> >
> > I'm not entirely clear what you're asking here. The callbacks you
> > mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we
> use
> > an SSL_SESSION object to encapsulate the PSK details. This is
> different
> > to session resumption, where the server sends the session details in
> a
> > NewSessionTicket message in one connection, so that we can "resume"
> it
> > in a later connection.
> >
> > So if your question is really "can you external session files for
> PSK in
> > TLSv1.2" then the answer is no. PSK works completely differently in
> > TLSv1.2.
> >
> >
> > Thanks Matt, Apologies for ambiguity in the question
> >
> > What I mean to ask is it possible to use out of band resumption in TLS
> 1.2?
> > How I perform the resumption in my programs using TLS 1.2 is as follows :
> > 1)  Connect client to the server  for the first time
> > 2) when the server sends session id or tickets as the case may be,
> > new_session_callback is invoked on the client side and I save the
> > session in a pem file using PEM_write_bio_SSL_SESSION
> > 3)Now when connecting client to the server next time, I read the session
> > from the pem file and set using SSL_set_session.
> > 4)Session resumption is initiated from the client side and the server
> > works as expected since it had been caching the session and was not
> killed.
> >
> > I observe that the second connection (and subsequent connections) takes
> > place using resumption. As per my understanding, this is called in-band
> > resumption
> >
> > Now my question is if, I kill the server. I re-initialze the server and
> > want to use the session(pem) file to connect to the server (this is a
> > fresh connection which should take place using resumption).
> > In that case, I will need to set the session on both the ends right? Is
> > this approach correct? In that case, how should one implement it.
> > This is out-of-band resumption for TLS 1.2 as per my understanding.
> > Please correct me if I am wrong
>
> The term out-of-band resumption is somewhat confusing. Anyway, the
> server maintains a session cache. That cache can either be internal
> (i.e. maintained by OpenSSL), or external (maintained by your own
> application code). In the default case a server will just use the
> internal session cache. You can populate that cache manually using
> SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
> objects (perhaps loaded from a file) you can manually populate that
> cache at application startup.
>



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. But then
how can that data be read on the client side since read_early_data api is
invalid on client side ?

Thanks
Best Regards,
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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

On 14/07/17 20:18, Neetish Pathak wrote:
> 
> 
> On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 13/07/17 23:52, Neetish Pathak wrote:
> > Hi All,
> > Help with these queries please,
> >
> > 1) Is it possible to use external session files (with session info as
> > identifiers or tickets for out of band resumption) for session
> > resumption in TLS 1.2. Does it need some kind of callback like the way
> > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> > SSL_set_psk_use_session_callback
> 
> I'm not entirely clear what you're asking here. The callbacks you
> mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
> an SSL_SESSION object to encapsulate the PSK details. This is different
> to session resumption, where the server sends the session details in a
> NewSessionTicket message in one connection, so that we can "resume" it
> in a later connection.
> 
> So if your question is really "can you external session files for PSK in
> TLSv1.2" then the answer is no. PSK works completely differently in
> TLSv1.2.
> 
> 
> Thanks Matt, Apologies for ambiguity in the question
> 
> What I mean to ask is it possible to use out of band resumption in TLS 1.2?
> How I perform the resumption in my programs using TLS 1.2 is as follows :
> 1)  Connect client to the server  for the first time
> 2) when the server sends session id or tickets as the case may be,
> new_session_callback is invoked on the client side and I save the
> session in a pem file using PEM_write_bio_SSL_SESSION
> 3)Now when connecting client to the server next time, I read the session
> from the pem file and set using SSL_set_session. 
> 4)Session resumption is initiated from the client side and the server
> works as expected since it had been caching the session and was not killed.
> 
> I observe that the second connection (and subsequent connections) takes
> place using resumption. As per my understanding, this is called in-band
> resumption
> 
> Now my question is if, I kill the server. I re-initialze the server and
> want to use the session(pem) file to connect to the server (this is a
> fresh connection which should take place using resumption).
> In that case, I will need to set the session on both the ends right? Is
> this approach correct? In that case, how should one implement it. 
> This is out-of-band resumption for TLS 1.2 as per my understanding.
> Please correct me if I am wrong

The term out-of-band resumption is somewhat confusing. Anyway, the
server maintains a session cache. That cache can either be internal
(i.e. maintained by OpenSSL), or external (maintained by your own
application code). In the default case a server will just use the
internal session cache. You can populate that cache manually using
SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
objects (perhaps loaded from a file) you can manually populate that
cache at application startup.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell  wrote:

>
>
> On 13/07/17 23:52, Neetish Pathak wrote:
> > Hi All,
> > Help with these queries please,
> >
> > 1) Is it possible to use external session files (with session info as
> > identifiers or tickets for out of band resumption) for session
> > resumption in TLS 1.2. Does it need some kind of callback like the way
> > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> > SSL_set_psk_use_session_callback
>
> I'm not entirely clear what you're asking here. The callbacks you
> mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
> an SSL_SESSION object to encapsulate the PSK details. This is different
> to session resumption, where the server sends the session details in a
> NewSessionTicket message in one connection, so that we can "resume" it
> in a later connection.
>
> So if your question is really "can you external session files for PSK in
> TLSv1.2" then the answer is no. PSK works completely differently in
> TLSv1.2.
>

Thanks Matt, Apologies for ambiguity in the question

What I mean to ask is it possible to use out of band resumption in TLS 1.2?
How I perform the resumption in my programs using TLS 1.2 is as follows :
1)  Connect client to the server  for the first time
2) when the server sends session id or tickets as the case may be,
new_session_callback is invoked on the client side and I save the session
in a pem file using PEM_write_bio_SSL_SESSION
3)Now when connecting client to the server next time, I read the session
from the pem file and set using SSL_set_session.
4)Session resumption is initiated from the client side and the server works
as expected since it had been caching the session and was not killed.

I observe that the second connection (and subsequent connections) takes
place using resumption. As per my understanding, this is called in-band
resumption

Now my question is if, I kill the server. I re-initialze the server and
want to use the session(pem) file to connect to the server (this is a fresh
connection which should take place using resumption).
In that case, I will need to set the session on both the ends right? Is
this approach correct? In that case, how should one implement it.
This is out-of-band resumption for TLS 1.2 as per my understanding.
Please correct me if I am wrong

Thanks
Best Regards,
Neetish


Thanks

>
>
> > 2) In TLS 1.3, is early data not enabled for out of band PSK session
> > resumption. Is it only possible with in-band session resumption.
> > SSL_write_early_data always fails when I load a session from a session
> > file to perform external PSK resumption before sending the session data.
> > For in-band resumption it succeeds.
>
> Currently we only support early-data for ticket based resumption. You
> cannot do it with an external PSK. However this PR (which is currently
> going through review) will add that capability:
>
> https://github.com/openssl/openssl/pull/3926
>
> 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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Matt Caswell]

On 13/07/17 23:52, Neetish Pathak wrote:
> Hi All,
> Help with these queries please,
> 
> 1) Is it possible to use external session files (with session info as
> identifiers or tickets for out of band resumption) for session
> resumption in TLS 1.2. Does it need some kind of callback like the way
> it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
> SSL_set_psk_use_session_callback

I'm not entirely clear what you're asking here. The callbacks you
mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
an SSL_SESSION object to encapsulate the PSK details. This is different
to session resumption, where the server sends the session details in a
NewSessionTicket message in one connection, so that we can "resume" it
in a later connection.

So if your question is really "can you external session files for PSK in
TLSv1.2" then the answer is no. PSK works completely differently in TLSv1.2.


> 2) In TLS 1.3, is early data not enabled for out of band PSK session
> resumption. Is it only possible with in-band session resumption. 
> SSL_write_early_data always fails when I load a session from a session
> file to perform external PSK resumption before sending the session data.
> For in-band resumption it succeeds.

Currently we only support early-data for ticket based resumption. You
cannot do it with an external PSK. However this PR (which is currently
going through review) will add that capability:

https://github.com/openssl/openssl/pull/3926

Matt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users