Re: [openssl-users] Research papers on TLS 1.3

[Neetish Pathak]

Thanks, Rich. Do you have the link to the mini-conference proceedings?

Thanks
Best Regards,
Neetish


On Wed, Oct 4, 2017 at 8:58 PM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> You should look at the IETF TLS working group.  Also, there was a mini
> conference, TLS Ready or Not, that has a bunch of useful papers.
>
>
>
>
>
> --
> 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

[openssl-users] Research papers on TLS 1.3

[Neetish Pathak]

Hi All,

Could you please suggest few research papers (apart from TLS 1.3 draft) on
TLS 1.3 that may b helpful to understand TLS 1.3 implementation and
performance. Is there any research available on TLS 1.3 performance
benchmarking?

Some papers which I am referring right now are:

   1.

   A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates
   


2) Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and
Delayed Authentication


Thanks
Best Regards,
Neetish
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [EXT] TLS 1.3 performance

[Neetish Pathak]

Thanks Roelof,

This is really helpful.

BR,
Neetish

On Thu, Sep 14, 2017 at 4:45 PM, Roelof Du Toit 
wrote:

> Hi Neetish,
>
>
>
> I would recommend considering the following in your research:
>
> - The impact of Nagle.  See https://github.com/openssl/openssl/issues/4237
>
> - The impact of the KeyShare calculation on TLS 1.3 session resumption
> (assuming most deployments will use psk_dhe_ke)
>
> - The impact of post-handshake handshake messages.
>
>
>
> Regards
>
> Roelof
>
>
>
> *From: *openssl-users  on behalf of
> Neetish Pathak 
> *Reply-To: *"openssl-users@openssl.org" 
> *Date: *Thursday, September 14, 2017 at 4:20 PM
> *To: *"openssl-users@openssl.org" 
> *Subject: *[EXT] [openssl-users] TLS 1.3 performance
>
>
>
> Hi,
>
>
>
> I worked on TLS 1.3 performance bench-marking. After my tests, I found
> that TLS 1.3 based resumption is not giving us the connection latency
> benefits when tested in a LAN environment. It is slower than TLS 1.2. When
> tested on WAN, definitely, TLS 1.3 fares better than TLS 1.2.
>
> I want your suggestion on whether can I work on the following problem for
> my research project: *"Investigating why TLS 1.3
> resumption/0-RTT/full-handshake doesn't provide the  desired connection
> latency benefits in LAN and the ways to make it faster?"*
>
> I want suggestions/references on the right research problem. Any ideas
> will be appreciated.
>
>
>
> Thanks in advance
>
>
>
> Thanks
>
> Best Regards,
>
> Neetish
>
> --
> 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

[openssl-users] TLS 1.3 performance

[Neetish Pathak]

Hi,

I worked on TLS 1.3 performance bench-marking. After my tests, I found that
TLS 1.3 based resumption is not giving us the connection latency benefits
when tested in a LAN environment. It is slower than TLS 1.2. When tested on
WAN, definitely, TLS 1.3 fares better than TLS 1.2.
I want your suggestion on whether can I work on the following problem for
my research project: *"Investigating why TLS 1.3
resumption/0-RTT/full-handshake doesn't provide the  desired connection
latency benefits in LAN and the ways to make it faster?"*
I want suggestions/references on the right research problem. Any ideas will
be appreciated.

Thanks in advance

Thanks
Best Regards,
Neetish
-- 
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 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.
>> &g

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 handsh

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 Po

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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_man3_SSL-5Fwrite-5Fearly-5Fdata.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=MfCOjAV83u4xGuIMb7VquiUt64_HFf9UC8LY4eIP_oc&s=ZAcBNcJWKTExKYdPPPOxcSr51esghiaZM82tPTLtbHM&e=>
>
>
>
> 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,

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

[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  > <mailto:m...@openssl.org>> 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

[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

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

[Neetish Pathak]

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


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.

Thanks
Best Regards,
Neetish
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Default Diffie Hellman Parameters

[Neetish Pathak]

Hi All,
In case no dh params are set and ECDHE-ECDSA type cipher is used, what is
the default size of DH params  (what modulus) used on TLS handshake. I see
that X25519 EC is getting used but I am not sure about DH parameters in
that case
Thanks
Best Regards,
Neetish
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Fwd: PSK generation for TLS 1.3

[Neetish Pathak]

I have a query regarding the TLS 1.3 handshake message exchange. Please
provide your comments.


With TLS 1.3, I see that Application Data Protocol message is sent from the
server side and client side (using wireshark) during the handshake. I am
only performing handshake and not doing any read write operations. I see
that servers and clients send application data protocol when doing just
SSL_connect and SSL_accept .

I also know that all the messages post server hello are encrypted in TLS
1.3. So, I am not sure what data gets exchanged
When checking logs for TLS 1.2, I do not see any exchange of Application
Data Protocol which is as expected.



Basically, connection sequence for TLS 1.2 is

*Client Hello*
*Server Hello, Certificate, Server Key Exchange, Certificate Request,
Server Hello Done*
*Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec,
Encrypted Handshake Message (Finished)*
*Change Cipher Spec, Encrypted Handshake Message (Finished)*



but for TLS 1.3, it is
The same is the sequence of messages exchanged when doing a connection
using resumption. I am not sure what application data gets exchanged when
doing TLS 1.3 when I am not doing any read/writes.
>From RFC, I can see that Application Data can be optionally sent at the end
of server Hello but I am not sure what data it is. How can I decrypt the
exchanged data ?
*Client Hello*
*Server Hello, Application Data Protocol from Server*
*Application Data Protocol from Client*
*Application Data Protocol from Server*
*Application Data Protocol from Client*


Also, I observe that resumption connection time for TLS 1.3 using PSK  is
more than resumption time for TLS 1.2 (by 700-800 microseconds). I am
suspecting the exchange of application data and its processing etc
(encryption) is causing the added delay. Could someone please provide any
explanation or point me in the right direction. It is not very clear to me
right now even after seeing the RFC

Thanks




On Thu, Jul 6, 2017 at 11:40 AM, Neetish Pathak  wrote:

> Thanks for the detailed explanation Matt
>
> On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell  wrote:
>
>>
>>
>> On 03/07/17 22:24, Neetish Pathak wrote:
>>
>> > Thanks Matt. This is quite useful.
>> > Just to clarify my understanding based on your comments, OpenSSL code
>> >  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following
>> queries
>> >
>> > 1) So, when using external PSK (by creating the new session file),
>> > client should mandatorily use SSL_CTX_set_psk_use_session_callback
>> while
>> > server should mandatorily use SSL_CTX_set_psk_find_session_casllback.
>> > They both should use a common key (psk_key) to generate the new session
>> > file and this common key is the one shared in advance to both client and
>> > server.
>>
>> Yes, that is correct. If both client and server are OpenSSL then,
>> optionally, they can just share a session file (which contains the key)
>> if that is easier.
>>
>> > From the OpenSSL code, this key is used as char * type. So does
>> > it mean that any pre-decided string can be used as a key and it does not
>> > need any format etc.
>>
>> To me "string" implies NUL terminated printable string. Maybe that's not
>> what you meant. Anyway in that sense "string" is not quite correct. The
>> key is binary data which should be the same length as the hash used for
>> the ciphersuite.
>>
>>
>> > Both client and server create sessions based on the
>> > key and connect based on the created session?
>> > In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
>> > used. So, I believe I can use any hex value string of my choice as
>> psk_key.
>>
>> Like I said above - the key is *binary* data. It does not have to be a
>> printable string.
>>
>>
>> > 2) Also, from the man page , I found that PSK are used in TLS1.2 and
>> > lower versions too and SSL_CTX_set_psk_server_callback
>> > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>> >  identity and Pre shared key is set there which can be used during the
>> > connection. It is also written that these values are required when using
>> > PSK cipher-suites. So, is my understanding correct that the role of PSK
>> > in version <= TLS1.2 is only for using PSK ciphersuites
>> > (e.g: ECDHE-PSK-AES256-CBC-SHA384)
>>
>> Correct.
>>
>> > and do not have anything to do with
>> > session resumption and thereby do not provide any performance
>> enhancement.
>>
>> They do not have anything to do with session resumption, so you don&#x

Re: [openssl-users] PSK generation for TLS 1.3

[Neetish Pathak]

On Mon, Jul 3, 2017 at 2:11 AM, Matt Caswell  wrote:

>
>
> On 30/06/17 22:18, Neetish Pathak wrote:
> > Hi All,
> > Can anyone provide me pointers on how can we generate external PSK to be
> > used inTLS 1.3.
> >
> > When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
> > in-band PSK for next resumption connection.
> > I use PEM_write_bio_SSL_SESSION to save the session.
> >
> >
> > How do we use PSK externally. Can I use the same session file which was
> > saved during in-band connection. I believe in case of an external PSK,
> > both client and server should have a copy in advance.
>
> Yes, you can do if you want - like you said you just need to make sure
> that the session file is used on both the client and the server.
> Alternatively you can "create" a new session file, e.g.
> s_server/s_client do it like this:
>
> usesess = SSL_SESSION_new();
> if (usesess == NULL
> || !SSL_SESSION_set1_master_key(usesess, key, key_len)
> || !SSL_SESSION_set_cipher(usesess, cipher)
> || !SSL_SESSION_set_protocol_version(usesess,
> TLS1_3_VERSION)) {
> OPENSSL_free(key);
> goto err;
> }
>
>
> Thanks Matt. This is quite useful.
Just to clarify my understanding based on your comments, OpenSSL code  and
Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries

1) So, when using external PSK (by creating the new session file), client
should mandatorily use SSL_CTX_set_psk_use_session_callback while server
should mandatorily use SSL_CTX_set_psk_find_session_callback.
They both should use a common key (psk_key) to generate the new session
file and this common key is the one shared in advance to both client and
server. From the OpenSSL code, this key is used as char * type. So does it
mean that any pre-decided string can be used as a key and it does not need
any format etc. Both client and server create sessions based on the key and
connect based on the created session?
In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
used. So, I believe I can use any hex value string of my choice as psk_key.


2) Also, from the man page , I found that PSK are used in TLS1.2 and lower
versions too and SSL_CTX_set_psk_server_callback and
SSL_CTX_set_psk_client_callback
are used to set callback there. PSK  identity and Pre shared key is set
there which can be used during the connection. It is also written that
these values are required when using PSK cipher-suites. So, is my
understanding correct that the role of PSK in version <= TLS1.2 is only for
using PSK ciphersuites (e.g: ECDHE-PSK-AES256-CBC-SHA384) and do not have
anything to do with session resumption and thereby do not provide any
performance enhancement.
Also, this PSK type ciphersuites are no longer valid for TLS 1.3.


Thanks
BR,
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

[openssl-users] PSK generation for TLS 1.3

[Neetish Pathak]

Hi All,
Can anyone provide me pointers on how can we generate external PSK to be
used inTLS 1.3.

When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
in-band PSK for next resumption connection.
I use PEM_write_bio_SSL_SESSION to save the session.


How do we use PSK externally. Can I use the same session file which was
saved during in-band connection. I believe in case of an external PSK, both
client and server should have a copy in advance.

Thanks
Best Regards,
Neetish
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading multiple private keys a certificates on server program

[Neetish Pathak]

Hi ,

I am building a server and client program. I wanted to know if the client
intends to use a particular cipher suite ECDHE256 ECDSA 256 types and
presents it to the server as its only ciphersuite. Then who decides the
Diffie-hellman and EC parameters. Should the parameters be decided on the
client side or the server side?

Thanks
Best Regards,
Neetish



On Tue, Jun 27, 2017 at 4:56 PM, Neetish Pathak  wrote:

> Thanks
> 1) How can i load multiple private keys and certificates on the server
> side.
> I need to use different keys and certificates when the client explicitly
> asks for a particular cipher.
> E.g The client can send the ciphersuite as
>
> ECDHE-RSA-AES256-GCM-SHA384 for first connection
> and then
>
> ECDHE-ECDSA-AES256-GCM-SHA384 for second connection
>
> Server should pick the right key and certificate (RSA and ECDSA certs
> respectively)
>
> I am using
>
> SSL_CTX_use_certificate_file to load the certificate but the server always
> picks just the first certificate mentioned in the file and fails for one of
> the cases with no cipher shared message
>
> What should we do to store multiple certificates and private keys at the
> server side so that it picks the right one corresponding to the requested
> cipher.
>
>
> Should I make certificate chain ?
>
> Should I make keystore? (PKCS12 etc)
>
> what API should be used to load the keys and certificates. Can somebody
> suggest the right way to do this.
> Thanks
> Best Regards,
> Neetish
>
>
> On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell  wrote:
>
>>
>>
>> On 27/06/17 01:05, Neetish Pathak wrote:
>> > Hi ,
>> >
>> > 1) I am working with a client and server program and want to use
>> > ECDHE-ECDSA type ciphers.
>> > I see that default Elliptic curve group supported is X25519. (when I
>> > check client  and server logs on wireshark)
>> > I wish to generate a self-signed certificate for X25519 curve. But I am
>> > unable to do that the way I do for other curves like secp256r1,
>> > secp521r1 etc.
>> >
>> > I generate a private key for secp521r1 using ecparam command and  then I
>> > generate the self-signed certificate.
>> >
>> > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
>> > server_key.pem
>> >
>> > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days
>> 730
>> >
>> >
>> > On man page for X25519,
>> >
>> > I found the command to generate private key
>> >
>> > openssl genpkey -algorithm X25519 -out xkey.pem
>> >
>> > But as I try to generate a self signed certificate, I am getting the
>> > following error
>> >
>> > EVP_PKEY_sign_init:operation not supported for this keytype
>>
>> It is not possible to "self-sign" an X25519 certificate because X25519
>> is a key-exchange algorithm only, not a digital signature algorithm. You
>> would not typically create an X25519 certificate at all but an Ed25519
>> one (only supported in the master branch).
>>
>>
>> >
>> >
>> > Could you please clarify where am I going wrong. Also, why is X25519 not
>> > mentioned
>> >
>> > in ec curve list
>> >
>> > using openssl ecparam -list_curves
>>
>> X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.
>> X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is
>> treated as a standalone algorithm and not integrated into the rest of
>> the EC logic.
>>
>> >
>> >
>> > Any references to clarify my understanding will be appreciated.
>> >
>> > 2) Also, can you direct me towards what hack is needed in Openssl to
>> > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
>> > study purpose).
>>
>> For external PSKs in TLS1.3 (again only supported in master), you need
>> to use the new
>> SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_
>> session_callback()
>> APIs. See the man pages in master for this (for some reason I notice
>> that the documentation for this has not been updated on the website -
>> but it *is* in the doc/man3 folder in git).
>>
>> >
>> > Are you planning to integrate false start in OpenSSL any time. Thanks
>>
>> I am not aware of anyone working on this.
>>
>> Matt
>>
>>
>> >
>> > Thanks
>> >
>> >
>> > Best Regards,
>> > Neetish
>> >
>> > On Wed, Jun

Re: [openssl-users] Loading multiple private keys a certificates on server program

[Neetish Pathak]

Thanks
1) How can i load multiple private keys and certificates on the server side.
I need to use different keys and certificates when the client explicitly
asks for a particular cipher.
E.g The client can send the ciphersuite as

ECDHE-RSA-AES256-GCM-SHA384 for first connection
and then

ECDHE-ECDSA-AES256-GCM-SHA384 for second connection

Server should pick the right key and certificate (RSA and ECDSA certs
respectively)

I am using

SSL_CTX_use_certificate_file to load the certificate but the server always
picks just the first certificate mentioned in the file and fails for one of
the cases with no cipher shared message

What should we do to store multiple certificates and private keys at the
server side so that it picks the right one corresponding to the requested
cipher.


Should I make certificate chain ?

Should I make keystore? (PKCS12 etc)

what API should be used to load the keys and certificates. Can somebody
suggest the right way to do this.
Thanks
Best Regards,
Neetish


On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell  wrote:

>
>
> On 27/06/17 01:05, Neetish Pathak wrote:
> > Hi ,
> >
> > 1) I am working with a client and server program and want to use
> > ECDHE-ECDSA type ciphers.
> > I see that default Elliptic curve group supported is X25519. (when I
> > check client  and server logs on wireshark)
> > I wish to generate a self-signed certificate for X25519 curve. But I am
> > unable to do that the way I do for other curves like secp256r1,
> > secp521r1 etc.
> >
> > I generate a private key for secp521r1 using ecparam command and  then I
> > generate the self-signed certificate.
> >
> > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
> > server_key.pem
> >
> > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730
> >
> >
> > On man page for X25519,
> >
> > I found the command to generate private key
> >
> > openssl genpkey -algorithm X25519 -out xkey.pem
> >
> > But as I try to generate a self signed certificate, I am getting the
> > following error
> >
> > EVP_PKEY_sign_init:operation not supported for this keytype
>
> It is not possible to "self-sign" an X25519 certificate because X25519
> is a key-exchange algorithm only, not a digital signature algorithm. You
> would not typically create an X25519 certificate at all but an Ed25519
> one (only supported in the master branch).
>
>
> >
> >
> > Could you please clarify where am I going wrong. Also, why is X25519 not
> > mentioned
> >
> > in ec curve list
> >
> > using openssl ecparam -list_curves
>
> X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.
> X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is
> treated as a standalone algorithm and not integrated into the rest of
> the EC logic.
>
> >
> >
> > Any references to clarify my understanding will be appreciated.
> >
> > 2) Also, can you direct me towards what hack is needed in Openssl to
> > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
> > study purpose).
>
> For external PSKs in TLS1.3 (again only supported in master), you need
> to use the new
> SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_
> find_session_callback()
> APIs. See the man pages in master for this (for some reason I notice
> that the documentation for this has not been updated on the website -
> but it *is* in the doc/man3 folder in git).
>
> >
> > Are you planning to integrate false start in OpenSSL any time. Thanks
>
> I am not aware of anyone working on this.
>
> Matt
>
>
> >
> > Thanks
> >
> >
> > Best Regards,
> > Neetish
> >
> > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  > <mailto:npath...@ncsu.edu>> wrote:
> >
> >
> >
> > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 21/06/17 00:38, Neetish Pathak wrote:
> > > I wanted to understand the replay attack vulnerability in case
> of enable
> > > early data of TLS 1.3 while false start is secure in that
> respect as I
> > > have read from https://github.com/openssl/openssl/issues/1541
> > <https://github.com/openssl/openssl/issues/1541>
> > > So, with false start, the application data is sent from client
> after the
> > > first leg of the handshake i.e. one round trip is complete, so
> the data
> > > goes encrypted even though the handshake is not co

[openssl-users] (no subject)

[Neetish Pathak]

Hi ,

1) I am working with a client and server program and want to use
ECDHE-ECDSA type ciphers.
I see that default Elliptic curve group supported is X25519. (when I check
client  and server logs on wireshark)
I wish to generate a self-signed certificate for X25519 curve. But I am
unable to do that the way I do for other curves like secp256r1, secp521r1
etc.

I generate a private key for secp521r1 using ecparam command and  then I
generate the self-signed certificate.

openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
server_key.pem

openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730


On man page for X25519,

I found the command to generate private key

openssl genpkey -algorithm X25519 -out xkey.pem

But as I try to generate a self signed certificate, I am getting the
following error

EVP_PKEY_sign_init:operation not supported for this keytype


Could you please clarify where am I going wrong. Also, why is X25519 not
mentioned

in ec curve list

using openssl ecparam -list_curves


Any references to clarify my understanding will be appreciated.

2) Also, can you direct me towards what hack is needed in Openssl to
support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
study purpose).

Are you planning to integrate false start in OpenSSL any time. Thanks

Thanks


Best Regards,
Neetish

On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  wrote:

>
>
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  wrote:
>
>>
>>
>> On 21/06/17 00:38, Neetish Pathak wrote:
>> > I wanted to understand the replay attack vulnerability in case of enable
>> > early data of TLS 1.3 while false start is secure in that respect as I
>> > have read from https://github.com/openssl/openssl/issues/1541
>> > So, with false start, the application data is sent from client after the
>> > first leg of the handshake i.e. one round trip is complete, so the data
>> > goes encrypted even though the handshake is not completed. In enable
>> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
>> > application data is sent from the client along with the client hello
>> > message. Does the application data in early data mode go as clear text ?
>>
>> No, it is encrypted using a traffic key derived from the PSK.
>>
>> > I assume this is also encrypted using the PSK because 0-RTT is only
>> > applicable when PSK is available on the client side. How is it
>> > vulnerable to replay attack. Please help me understand.
>>
>> The same PSK can be used multiple times. Because the traffic key for the
>> early data is derived from the PSK, if you later re-use the PSK and send
>> early data again then the same traffic key will be derived. This can be
>> exploited by an attacker who can record the early data from an earlier
>> session and replay it later. The server will think that the replayed
>> data is a new connection and process the early data accordingly.
>>
>> Early data (aka 0-RTT data) can be dangerous if not used properly. For
>> this reason the current TLSv1.3 draft makes this note:
>>
>>Protocols MUST NOT use 0-RTT data without a profile that defines its
>>use.  That profile needs to identify which messages or interactions
>>are safe to use with 0-RTT.  In addition, to avoid accidental misuse,
>>implementations SHOULD NOT enable 0-RTT unless specifically
>>requested.  Implementations SHOULD provide special functions for
>>0-RTT data to ensure that an application is always aware that it is
>>sending or receiving data that might be replayed.
>>
>>
>> >
>> > Is there any API available in OpenSSL for false start ?
>>
>> No, OpenSSL does not support false start. As an aside please note that
>> false start only applies to <= TLSv1.2.
>
>
> Thanks for your comments.
>
> I need some direction on the doing server and client side authentication
> during the handshake.
>
> *1) For certificate sent from the server side, I am using*
>
> SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL))   for loading
> verification file *on the client side*
>
> Where do I get a CAFILE in the above API. If the server is sending a self
> signed certificate, what will be the CA file on the client side for
> verification.
>
>
> *2) For Client side authentication*
>
> I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file
> on the client side to load the private key and the certificate.
> I read that client side authentication will not kick off unless the server
> sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that
> sets the client_cert_cb() callback to be called on Certif

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  wrote:

>
>
> On 21/06/17 00:38, Neetish Pathak wrote:
> > I wanted to understand the replay attack vulnerability in case of enable
> > early data of TLS 1.3 while false start is secure in that respect as I
> > have read from https://github.com/openssl/openssl/issues/1541
> > So, with false start, the application data is sent from client after the
> > first leg of the handshake i.e. one round trip is complete, so the data
> > goes encrypted even though the handshake is not completed. In enable
> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
> > application data is sent from the client along with the client hello
> > message. Does the application data in early data mode go as clear text ?
>
> No, it is encrypted using a traffic key derived from the PSK.
>
> > I assume this is also encrypted using the PSK because 0-RTT is only
> > applicable when PSK is available on the client side. How is it
> > vulnerable to replay attack. Please help me understand.
>
> The same PSK can be used multiple times. Because the traffic key for the
> early data is derived from the PSK, if you later re-use the PSK and send
> early data again then the same traffic key will be derived. This can be
> exploited by an attacker who can record the early data from an earlier
> session and replay it later. The server will think that the replayed
> data is a new connection and process the early data accordingly.
>
> Early data (aka 0-RTT data) can be dangerous if not used properly. For
> this reason the current TLSv1.3 draft makes this note:
>
>Protocols MUST NOT use 0-RTT data without a profile that defines its
>use.  That profile needs to identify which messages or interactions
>are safe to use with 0-RTT.  In addition, to avoid accidental misuse,
>implementations SHOULD NOT enable 0-RTT unless specifically
>requested.  Implementations SHOULD provide special functions for
>0-RTT data to ensure that an application is always aware that it is
>sending or receiving data that might be replayed.
>
>
> >
> > Is there any API available in OpenSSL for false start ?
>
> No, OpenSSL does not support false start. As an aside please note that
> false start only applies to <= TLSv1.2.


Thanks for your comments.

I need some direction on the doing server and client side authentication
during the handshake.

*1) For certificate sent from the server side, I am using*

SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL))   for loading
verification file *on the client side*

Where do I get a CAFILE in the above API. If the server is sending a self
signed certificate, what will be the CA file on the client side for
verification.


*2) For Client side authentication*

I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file on
the client side to load the private key and the certificate.
I read that client side authentication will not kick off unless the server
sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that sets
the client_cert_cb() callback to be called on CertificateRequest.

I am not sure how I can enable the server side to send CertificateRequest.
What is the API for that.
Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on
server side for sending the certificateRequest message. Please correct me ?

*3) Certificate request Message*
Also, what is the use of CertificateVerify message. Why does client need to
prove the ownership of private key for the public key sent previously in
the client certificate. I assume this is not happening when the server
sends the certificate. It doesn't prove the ownership of private key.Please
comment



Also, some guidance on a reference for understanding the authentication of
certificates will be appreciated


Thanks
Neetish


>
>
> Matt
>
> >
> > Thanks
> > Best regards,
> > Neetish
> >
> > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak  > <mailto:npath...@ncsu.edu>> wrote:
> >
> > I Appreciate your response
> >
> > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 19/06/17 19:11, Neetish Pathak wrote:
> > > 2) Can you suggest some places to put a time stamp in OpenSSL
> code.
> >
> > I agree with Ben's responses to all your other questions. For
> this
> > question, I'm not sure what you are trying to achieve? Starting
> > before
> > SSL_accept/SSL_connect and finishing after they return should be
> > fine.
> > Or are you looking for a breakdown of where the time is going?
> >

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I wanted to understand the replay attack vulnerability in case of enable
early data of TLS 1.3 while false start is secure in that respect as I have
read from https://github.com/openssl/openssl/issues/1541
So, with false start, the application data is sent from client after the
first leg of the handshake i.e. one round trip is complete, so the data
goes encrypted even though the handshake is not completed. In enable early
data mode in TLS 1.3 for 0-RTT for session resumption, the application data
is sent from the client along with the client hello message. Does the
application data in early data mode go as clear text ? I assume this is
also encrypted using the PSK because 0-RTT is only applicable when PSK is
available on the client side. How is it vulnerable to replay attack. Please
help me understand.

Is there any API available in OpenSSL for false start ?

Thanks
Best regards,
Neetish

On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak  wrote:

> I Appreciate your response
>
> On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  wrote:
>
>>
>>
>> On 19/06/17 19:11, Neetish Pathak wrote:
>> > 2) Can you suggest some places to put a time stamp in OpenSSL code.
>>
>> I agree with Ben's responses to all your other questions. For this
>> question, I'm not sure what you are trying to achieve? Starting before
>> SSL_accept/SSL_connect and finishing after they return should be fine.
>> Or are you looking for a breakdown of where the time is going?
>>
>> Thanks Matt. I was asking for a breakdown since I was not sure if the
>> SSL_accept and SSL_connect just do the handshake or if they are doing some
>> other things that may impact latency and CPU usage. Just wanted to be clear
>> that calling SSL_connect  starts ClientHello , SSL_accept unblocks on
>> receiving ClientHello and sends ServerHello, and both functions return
>> after sending Finished message from their sides (i.e. client and server).
>
>
>
>
>
>> Matt
>>
>> >
>> > Thanks
>> > Best Regards,
>> > Neetish
>> >
>> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > <mailto:m...@openssl.org>> wrote:
>> >
>> >
>> >
>> > On 16/06/17 23:51, Neetish Pathak wrote:
>> > > Thanks Matt, Appreciate ur response and tips
>> > >
>> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > <mailto:m...@openssl.org>
>> > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
>> > >
>> > >
>> > >
>> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
>> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> > > >> Hello
>> > > >> Thanks
>> > > >> I tried reading  some content from the server side and I
>> > observed the
>> > > >> new_session_cb getting invoked in that case on the client
>> > side. I
>> > > >> understand that may be due to delayed NewSession info
>> > transfer from
>> > > >> server side to client side. But it is helpful for saving
>> > the session
>> > > >> info on the client side. (Thanks Matt for your input)
>> > > >>
>> > > >> However, now I have two concerns
>> > > >>
>> > > >> 1) I see that latency for handshake with session
>> resumption in
>> > > TLS 1.3
>> > > >> has not improved as much as it improves for TLS 1.2
>> > > >> With TLS 1.3, I observed that resumption brings down the
>> > connection
>> > > >> time from 2.5 ms to 1.2-1.3 ms
>> > > >> while with TLS 1.2 (using either session IDs or tickets),
>> the
>> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>> > > >>
>> > > >> The whole code is similar for running the two experiments
>> > with only
>> > > >> max TLS version changed. Can someone comment on the latency
>> > > >> measurements for the two cases.
>> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
>> > opinion. Please
>> > > >> comment.
>> > > >>
>> > > >
>> > > > Are you seeing a HelloRetryRequest in the resumption flow?
>&

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I Appreciate your response

On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  wrote:

>
>
> On 19/06/17 19:11, Neetish Pathak wrote:
> > 2) Can you suggest some places to put a time stamp in OpenSSL code.
>
> I agree with Ben's responses to all your other questions. For this
> question, I'm not sure what you are trying to achieve? Starting before
> SSL_accept/SSL_connect and finishing after they return should be fine.
> Or are you looking for a breakdown of where the time is going?
>
> Thanks Matt. I was asking for a breakdown since I was not sure if the
> SSL_accept and SSL_connect just do the handshake or if they are doing some
> other things that may impact latency and CPU usage. Just wanted to be clear
> that calling SSL_connect  starts ClientHello , SSL_accept unblocks on
> receiving ClientHello and sends ServerHello, and both functions return
> after sending Finished message from their sides (i.e. client and server).





> Matt
>
> >
> > Thanks
> > Best Regards,
> > Neetish
> >
> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 16/06/17 23:51, Neetish Pathak wrote:
> > > Thanks Matt, Appreciate ur response and tips
> > >
> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  <mailto:m...@openssl.org>
> > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> > >
> > >
> > >
> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > > >> Hello
> > > >> Thanks
> > > >> I tried reading  some content from the server side and I
> > observed the
> > > >> new_session_cb getting invoked in that case on the client
> > side. I
> > > >> understand that may be due to delayed NewSession info
> > transfer from
> > > >> server side to client side. But it is helpful for saving
> > the session
> > > >> info on the client side. (Thanks Matt for your input)
> > > >>
> > > >> However, now I have two concerns
> > > >>
> > > >> 1) I see that latency for handshake with session resumption
> in
> > > TLS 1.3
> > > >> has not improved as much as it improves for TLS 1.2
> > > >> With TLS 1.3, I observed that resumption brings down the
> > connection
> > > >> time from 2.5 ms to 1.2-1.3 ms
> > > >> while with TLS 1.2 (using either session IDs or tickets),
> the
> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > > >>
> > > >> The whole code is similar for running the two experiments
> > with only
> > > >> max TLS version changed. Can someone comment on the latency
> > > >> measurements for the two cases.
> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
> > opinion. Please
> > > >> comment.
> > > >>
> > > >
> > > > Are you seeing a HelloRetryRequest in the resumption flow?
> > That would
> > > > add an additional round trip.  (Your numbers in milliseconds
> > are of
> > > > course not transferrable to other systems; round-trips is an
> > easier to
> > > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20
> > both have
> > > > message-flow diagrams that show the number of round trips in
> > various
> > > > handshake flows.
> > >
> > > Care should also be taken about when you are starting your
> > "timer" and
> > > when you stop it, e.g. if you stop your timer after the
> > session ticket
> > > data has been received by the client then this is not a "fair"
> > test (the
> > > connection is ready for data transfer earlier than the arrival
> > of the
> > > session ticket).
> > >
> > > I would expect to see the TLS1.3 latency for a full handshake
> > to be
> > > around the same as for a TLS1.2 resumption handshake. With a
> > TLS1.3
> > > resumption only

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Ben for all the replies and your comments. They are extremely useful
for my study

On Mon, Jun 19, 2017 at 9:21 PM, Benjamin Kaduk  wrote:

> On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak 
> wrote:
>
>> Hi Matt,
>> Thanks
>> Could you help with following queries
>>
>> 1) On the blogpost for TLS1.3, you mentions the following in the session
>> section
>> The specification recommends that applications only use a session once
>> (although this is not enforced). For this reason some servers send multiple
>> session messages to a client. To enforce the “use once” recommendation
>> applications could use SSL_CTX_remove_session() to mark a session as
>> non-resumable (and remove it from the cache) once it has been used.
>>
>> I am a bit confused here as to why "use once" is recommended. How will
>> resumption be ensured then ? I get a PSK in first connection and use it
>> again for all the other connections.
>>
>>
> "use once" is recommended in a limited circumstance, to prevent an
> attacker listening on the network from associating the (multiple) resumed
> sessions as being derived from the initial session.
> This is a new possibility in TLS 1.3, since in TLS 1.2 the session ticket
> was given to the client in cleartext (and presented back to the server in
> cleartext), so all uses of the ticket were traceable back to the original
> connection and linkable to each other.
>
> Using a given ticket more than once in TLS 1.3 just brings things back to
> basically the TLS 1.2 state in terms of linkability; it's not a
> catastrophic failure or anything like that.
>
>
>> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:
>>
>>>
>>>
> Yes Matt, when I switch to remote machines and test my application
> programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection
> (around same time as resumption time in TLS 1.2) itself and there is
> marginal or no improvement in the subsequent connections even on using
> resumption. Does this mean that resumption in TLS 1.3 is bringing not much
> benefit in terms of latency. It makes sense because round trips count for
> resumption or no resumption is 1 in TLS 1.3.
>
> The only benefit with resumption is that the client can now send zero-RTT
> data. (early data). However, if we consider the overall latency in
> handshake, it is going to be the same equivalent to 1 round trip.
> Is my understanding correct ?
>
> Is there any way to enable early data or it gets activated by default once
> the pre-shared keys are available at both the client and server ends ?
>
>
> No no no no no, many times no.
> You really must not blindly enable early data without a proper protocol
> analysis to determine what would happen if an attacker replayed the early
> data millions of times, as is possible with the current TLS 1.3 draft
> specification.  There are a lot of ways to hurt yourself and your users
> with it, and I strongly recommend against trying to enable it just because
> it looks faster.
> (There are separate APIs from the normal read/write APIs to use early
> data, to make you explicitly think about whether it's safe when adding
> support to an application.)
>
>
>
The comments give me much food for thought. I am still wondering on  on the
possibility for replay attacks when early data is enabled. Sorry, I am new
to OpenSSL or TLS and have so many doubts. So, I understood replay attacks
are possible as in early data enabled mode, data will go in the cleartext
form along with clientHello, so a middleman can look into the data and
replay it later. I was thinking if we use some kind of sequence number/
timestamps (as possible solution) to avoid this or it has been implemented
in OpenSSL ?
I am using the application for an internal project which is not going to be
public. So, I am wondering if it can be used. Nevertheless, your
recommendation is duly noted.


> I believe session resumption as a concept doesn't hold that much value
> from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
> connection. Do you agree?
>
>
> No.  Resumption saves on transferring (and validating!) certificates and
> can be done without incurring the cost of an additional diffie-hellman
> exchange, among other things.
>
> -Ben
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  wrote:

> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the session
> section
> The specification recommends that applications only use a session once
> (although this is not enforced). For this reason some servers send multiple
> session messages to a client. To enforce the “use once” recommendation
> applications could use SSL_CTX_remove_session() to mark a session as
> non-resumable (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How will
> resumption be ensured then ? I get a PSK in first connection and use it
> again for all the other connections.
>
>
> 2) Can you suggest some places to put a time stamp in OpenSSL code.
>
> Thanks
> Best Regards,
> Neetish
>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:
>
>>
>>
>> On 16/06/17 23:51, Neetish Pathak wrote:
>> > Thanks Matt, Appreciate ur response and tips
>> >
>> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > <mailto:m...@openssl.org>> wrote:
>> >
>> >
>> >
>> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
>> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> > >> Hello
>> > >> Thanks
>> > >> I tried reading  some content from the server side and I
>> observed the
>> > >> new_session_cb getting invoked in that case on the client side. I
>> > >> understand that may be due to delayed NewSession info transfer
>> from
>> > >> server side to client side. But it is helpful for saving the
>> session
>> > >> info on the client side. (Thanks Matt for your input)
>> > >>
>> > >> However, now I have two concerns
>> > >>
>> > >> 1) I see that latency for handshake with session resumption in
>> > TLS 1.3
>> > >> has not improved as much as it improves for TLS 1.2
>> > >> With TLS 1.3, I observed that resumption brings down the
>> connection
>> > >> time from 2.5 ms to 1.2-1.3 ms
>> > >> while with TLS 1.2 (using either session IDs or tickets), the
>> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>> > >>
>> > >> The whole code is similar for running the two experiments with
>> only
>> > >> max TLS version changed. Can someone comment on the latency
>> > >> measurements for the two cases.
>> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
>> Please
>> > >> comment.
>> > >>
>> > >
>> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
>> would
>> > > add an additional round trip.  (Your numbers in milliseconds are
>> of
>> > > course not transferrable to other systems; round-trips is an
>> easier to
>> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both
>> have
>> > > message-flow diagrams that show the number of round trips in
>> various
>> > > handshake flows.
>> >
>> > Care should also be taken about when you are starting your "timer"
>> and
>> > when you stop it, e.g. if you stop your timer after the session
>> ticket
>> > data has been received by the client then this is not a "fair" test
>> (the
>> > connection is ready for data transfer earlier than the arrival of
>> the
>> > session ticket).
>> >
>> > I would expect to see the TLS1.3 latency for a full handshake to be
>> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
>> > resumption only marginally different. There are the same number of
>> round
>> > trips for a TLS1.3 full handshake as that there are for a resumption
>> > one. The primary difference is that the Certificate message is not
>> sent
>> > (which can be quite a large message).
>>
>

Yes Matt, when I switch to remote machines and test my application
programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection
(around same time as resumption time in TLS 1.2) itself and there is
marginal or no improvement in the subsequent connections even on using
resumption. Does this mean that res

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Hi Matt,
Thanks
Could you help with following queries

1) On the blogpost for TLS1.3, you mentions the following in the session
section
The specification recommends that applications only use a session once
(although this is not enforced). For this reason some servers send multiple
session messages to a client. To enforce the “use once” recommendation
applications could use SSL_CTX_remove_session() to mark a session as
non-resumable (and remove it from the cache) once it has been used.

I am a bit confused here as to why "use once" is recommended. How will
resumption be ensured then ? I get a PSK in first connection and use it
again for all the other connections.


2) Can you suggest some places to put a time stamp in OpenSSL code.

Thanks
Best Regards,
Neetish

On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:

>
>
> On 16/06/17 23:51, Neetish Pathak wrote:
> > Thanks Matt, Appreciate ur response and tips
> >
> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > >> Hello
> > >> Thanks
> > >> I tried reading  some content from the server side and I observed
> the
> > >> new_session_cb getting invoked in that case on the client side. I
> > >> understand that may be due to delayed NewSession info transfer
> from
> > >> server side to client side. But it is helpful for saving the
> session
> > >> info on the client side. (Thanks Matt for your input)
> > >>
> > >> However, now I have two concerns
> > >>
> > >> 1) I see that latency for handshake with session resumption in
> > TLS 1.3
> > >> has not improved as much as it improves for TLS 1.2
> > >> With TLS 1.3, I observed that resumption brings down the
> connection
> > >> time from 2.5 ms to 1.2-1.3 ms
> > >> while with TLS 1.2 (using either session IDs or tickets), the
> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > >>
> > >> The whole code is similar for running the two experiments with
> only
> > >> max TLS version changed. Can someone comment on the latency
> > >> measurements for the two cases.
> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
> Please
> > >> comment.
> > >>
> > >
> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
> would
> > > add an additional round trip.  (Your numbers in milliseconds are of
> > > course not transferrable to other systems; round-trips is an
> easier to
> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > > message-flow diagrams that show the number of round trips in
> various
> > > handshake flows.
> >
> > Care should also be taken about when you are starting your "timer"
> and
> > when you stop it, e.g. if you stop your timer after the session
> ticket
> > data has been received by the client then this is not a "fair" test
> (the
> > connection is ready for data transfer earlier than the arrival of the
> > session ticket).
> >
> > I would expect to see the TLS1.3 latency for a full handshake to be
> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> > resumption only marginally different. There are the same number of
> round
> > trips for a TLS1.3 full handshake as that there are for a resumption
> > one. The primary difference is that the Certificate message is not
> sent
> > (which can be quite a large message).
> >
> > Your timings suggest you are testing this over a LAN where the
> effects
> > of network latency are going to be relatively low. The real benefits
> > from fewer round trips will really be seen when network latency is
> more
> > significant.
> >
> >
> >
> > In my application program, I put start and stop timer before and after
> > SSL_accept on server side and before and after SSL_connect on the client
> > side.
>
> That should be fine (my worry was that you might also be including the
> subsequent session ticket transfer).
>
> > I am not sure how I can put timers at individual steps of Handshake
> > using my client applications. I was assuming SSL and SSL_accept take
> > care of the entire h

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Benjamin/Matt,
Appreciate your tips and help so far.
Could you give me any pointers for placing my timestamps within the OpenSSl
code for right measurement for handshake. I am reading through the master
code. I think since in TLS 1.3 is session tickets are sent after handshake,
it would be ok to place a timestamp in the
*ossl_statem_server_pre_work *function
before *tls_finish_handshake* is called (This function is in state_srvr.c
which updates the stjatemachine I think). *It is only called for TLS 1.3*
*But I do not see any significant change when I put a timestamp here or at
the end of SSL_accept on my server application program.*
*Any help for the right location of time stamps will be appreciated.*

  *case* *TLS_ST_SW_SESSION_TICKET*:

*if* (SSL_IS_TLS13(s)) {

/*

 * Actually this is the end of the handshake, but we're going

 * straight into writing the session ticket out. So we finish
off

 * the handshake, but keep the various buffers active.

 */


/***End time
stamp*/

*struct* timespec end;

*clock_gettime*(CLOCK_MONOTONIC_RAW, &end);

uint64_t tempTimeEnd = end.tv_nsec / 1000;

*printf*("Handshake End time : %llu \n", tempTimeEnd);


*return* tls_finish_handshake(s, wst, 0);

} *if* (SSL_IS_DTLS(s)) {

/*

 * We're into the last flight. We don't retransmit the last
flight

 * unless we need to, so we don't use the timer

 */

st->use_timer = 0;

}


Thanks

BR,

Neetish

On Fri, Jun 16, 2017 at 5:54 PM, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> On 06/16/2017 05:36 PM, Matt Caswell wrote:
>
> The security properties of such "external" PSKs are substantially
> different than the "ephemeral" PSKs used in resumption flows.
>
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?
>
>
> The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable,
> and in terms of concrete differences, there are additional requirements on
> external PSKs that the KDF and PSK identity must remain fixed across uses.
> That, combined with the potential for insufficient entropy during key
> generation (mentioned in section 2.2 of draft-20) seem to provide more
> openings for cryptographic attacks than for the full resumption flow.  It
> is probably fine for uses where the other properties of external PSKs are
> needed, but I'm not sure that the risk/reward balance favors using it just
> to get a speedup -- TLS 1.3 resumption should already be pretty fast.
>
> -Ben
>
> --
> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Matt, Appreciate ur response and tips

On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  wrote:

>
>
> On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> >> Hello
> >> Thanks
> >> I tried reading  some content from the server side and I observed the
> >> new_session_cb getting invoked in that case on the client side. I
> >> understand that may be due to delayed NewSession info transfer from
> >> server side to client side. But it is helpful for saving the session
> >> info on the client side. (Thanks Matt for your input)
> >>
> >> However, now I have two concerns
> >>
> >> 1) I see that latency for handshake with session resumption in TLS 1.3
> >> has not improved as much as it improves for TLS 1.2
> >> With TLS 1.3, I observed that resumption brings down the connection
> >> time from 2.5 ms to 1.2-1.3 ms
> >> while with TLS 1.2 (using either session IDs or tickets), the
> >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> >>
> >> The whole code is similar for running the two experiments with only
> >> max TLS version changed. Can someone comment on the latency
> >> measurements for the two cases.
> >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> >> comment.
> >>
> >
> > Are you seeing a HelloRetryRequest in the resumption flow?  That would
> > add an additional round trip.  (Your numbers in milliseconds are of
> > course not transferrable to other systems; round-trips is an easier to
> > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > message-flow diagrams that show the number of round trips in various
> > handshake flows.
>
> Care should also be taken about when you are starting your "timer" and
> when you stop it, e.g. if you stop your timer after the session ticket
> data has been received by the client then this is not a "fair" test (the
> connection is ready for data transfer earlier than the arrival of the
> session ticket).
>
> I would expect to see the TLS1.3 latency for a full handshake to be
> around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> resumption only marginally different. There are the same number of round
> trips for a TLS1.3 full handshake as that there are for a resumption
> one. The primary difference is that the Certificate message is not sent
> (which can be quite a large message).
>
> Your timings suggest you are testing this over a LAN where the effects
> of network latency are going to be relatively low. The real benefits
> from fewer round trips will really be seen when network latency is more
> significant.
>


In my application program, I put start and stop timer before and after
SSL_accept on server side and before and after SSL_connect on the client
side.
I am not sure how I can put timers at individual steps of Handshake using
my client applications. I was assuming SSL and SSL_accept take care of the
entire handshake process.

Yes, I am testing on local machine. I will migrate my test to remote
machines. But I am not really able to understand why TLS 1.3 is slower on
my machine.

Also, it is difficult to see all the messages for TLS 1.3 since all
messages after server hello are encrypted when I see on Wireshark. So I am
not sure where exactly session ticket info is exchanged

>
> >
> >> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS
> >> 1.3 RFC. How do we generate pre-shared keys in advance even without
> >> making the first connection. Can someone guide me in the right
> direction.
>
> As Ben says this is not currently supported in master but there is
> pending WIP PR to add it.
>
> >>
> >
> > The security properties of such "external" PSKs are substantially
> > different than the "ephemeral" PSKs used in resumption flows.
>
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?
>
> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Hello
Thanks
I tried reading  some content from the server side and I observed the
new_session_cb getting invoked in that case on the client side. I
understand that may be due to delayed NewSession info transfer from server
side to client side. But it is helpful for saving the session info on the
client side. (Thanks Matt for your input)

However, now I have two concerns

1) I see that latency for handshake with session resumption in TLS 1.3 has
not improved as much as it improves for TLS 1.2
With TLS 1.3, I observed that resumption brings down the connection time
from 2.5 ms to 1.2-1.3 ms
while with TLS 1.2 (using either session IDs or tickets), the connection
time reduces from 2.5 ms to 0.5-0.6 ms.

The whole code is similar for running the two experiments with only max TLS
version changed. Can someone comment on the latency measurements for the
two cases.
TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please comment.

2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS 1.3
RFC. How do we generate pre-shared keys in advance even without making the
first connection. Can someone guide me in the right direction.

Thanks
Best Regards,
Neetish

On Thu, Jun 15, 2017 at 2:30 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 18:36, Neetish Pathak wrote:
> >
> > My calling sequence is :
> >
> > client.connectToServer();
> >
> > client.sslTcpConnect();
> >
> > client.sslTcpClosure();
>
> Does your client at any point attempt to read application data (i.e.
> through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to
> just connect to a server via SSL_connect(). Because the session
> information is established *post* handshake in TLSv1.3, OpenSSL won't
> see it unless you actually try and read information from the connection.
>
> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Wed, Jun 14, 2017 at 3:43 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 01:38, Salz, Rich via openssl-users wrote:
> > It’s disabled by default.  Servers that want to use server-side session
> > caching have to call an API to turn it on
>
> Err, no, that's not correct. Server side caching is on by default.
> Client side caching is off by default.
>


I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

"All sessions must have a session ID context. For the server, session
caching is disabled by default unless a call to SSL_CTX_set_session_id_context
is made."

That's why I thought server side session caching is disabled by default.


>
>
> On 14/06/17 02:03, Neetish Pathak wrote:
> > Thanks for your reply Salz. However, I want to know should the session
> > caching be enabled on server side for TLS 1.3 for session resumption.
>
> It should just work by default for TLSv1.3. You don't need to enable
> anything.
>

Yea it worked for previous TLS versions, so everything was inline. But
since with TLS 1.3, I was not observing the same behavior, that's why my
question was for TLS 1.3.

>
> > Also, I need a clarification on how does resumption work in case of
> > session identifiers if server side caching is not enabled
>
> As noted above server side caching is on by default.
>




>
> On 14/06/17 02:33, Neetish Pathak wrote:
> > I need some suggestions on how I can implement session resumption in TLS
> > 1.3. I have implemented the resumption on the client side using a
> > callback as recommended on the TLS 1.3
> > blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
> > <https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/> . Still, the
> > session resumption is not working. I know this because my new_session_cb
> > which I have set using SSL_CTX_sess_set_new_cb is never getting invoked
> > and also I don't see any improvement in connection time.
> >
> > The same implementation when I change the max TLS version to TLS1.2
> > works and session resumption works as desired.
> > I am not sure how I can resolve this.
> >
> > As mentioned on the blog post
> >
> > "In TLSv1.3 sessions are not established until after the main handshake
> > has completed. The server sends a separate post-handshake message to the
> > client containing the session details. Typically this will happen soon
> > after the handshake has completed, but it could be sometime later (or
> > not at all)."
> >
> > I think the server is not informing the session details to client at all
> > in my case and hence the resumption is not working. Can someone please
> > suggest how to resolve this
>
> Just to be clear: you are using OpenSSL on both the server and client
> sides right? If you are using something other than OpenSSL on the server
> then the policy might be different around when the session information
> is sent to the client (i.e. it could happen sometime later, or not at
> all). If you are using OpenSSL on the server then it sends its session
> information immediately after the main handshake has completed, so that
> should not be a problem.
>
> So if I understand you correctly the client is successfully creating a
> TLSv1.3 connection, but the client side new session callback is never
> being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after
> the SSL object itself was created? Are you able to share any code for
> how you have done this?
>



Yes, I am using OpenSSl on both the server and client sides and my
implementation works for TLS 1.2.
Yea you understood correctly, the client is creating a connection but new
session callback is not getting invoked.
I have called SSL_CTX_sess_set_new_cb before SSL object is created



Yea, sure following is a snippet from my client side implementation. I have
highlighted the relevant section for new session callback registration



*static* *int* *new_session_cb*(SSL* ssl, SSL_SESSION * sess){



BIO *stmp = BIO_new_file(SESS_OUT,"w");


*if*(stmp == NULL){

BIO_printf(bio_err,"Error writing session file %s\n",SESS_OUT);

}*else*{

fprintf(stderr,"Session getting set\n");

PEM_write_bio_SSL_SESSION(stmp,sess);

BIO_free(stmp);

resumeInput = TRUE;

}


*return* 0;

}


*int* *SocketClient::connectToServer*(){


/*Initialization

** (1)Register SSL/TLS ciphers and digests

** (2)Load Opessl error Strings*/

init_OpenSSL();


/*Creating a new SSL context object*/

ssl_ctx = SSL_CTX_new(TLS_client_method());

SSL_CTX_set_max_proto_version(ssl_ctx, MAX_TLS_VERSION);

SSL_CTX_set_min_proto_version(ssl_ctx, MIN_TLS_VERSION);


*if*(NULL == ssl_ctx){

fail("SocketClient.cpp : ssl_ctx object crea

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I need some suggestions on how I can implement session resumption in TLS
1.3. I have implemented the resumption on the client side using a callback
as recommended on the TLS 1.3 blog https://www.openssl.org/blog/b
log/2017/05/04/tlsv1.3/ . Still, the session resumption is not working. I
know this because my new_session_cb which I have set using
SSL_CTX_sess_set_new_cb
is never getting invoked and also I don't see any improvement in connection
time.

The same implementation when I change the max TLS version to TLS1.2 works
and session resumption works as desired.
I am not sure how I can resolve this.

As mentioned on the blog post

"In TLSv1.3 sessions are not established until after the main handshake has
completed. The server sends a separate post-handshake message to the client
containing the session details. Typically this will happen soon after the
handshake has completed, but it could be sometime later (or not at all)."

I think the server is not informing the session details to client at all in
my case and hence the resumption is not working. Can someone please suggest
how to resolve this.

Thanks
Best Regards,
Neetish


On Tue, Jun 13, 2017 at 6:03 PM, Neetish Pathak  wrote:

> Thanks for your reply Salz. However, I want to know should the session
> caching be enabled on server side for TLS 1.3 for session resumption.
> Also, I need a clarification on how does resumption work in case of
> session identifiers if server side caching is not enabled
>
> Thanks
> BR,
> Neetish
>
> On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users <
> openssl-users@openssl.org> wrote:
>
>> It’s disabled by default.  Servers that want to use server-side session
>> caching have to call an API to turn it on
>>
>> --
>> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks for your reply Salz. However, I want to know should the session
caching be enabled on server side for TLS 1.3 for session resumption.
Also, I need a clarification on how does resumption work in case of session
identifiers if server side caching is not enabled

Thanks
BR,
Neetish

On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> It’s disabled by default.  Servers that want to use server-side session
> caching have to call an API to turn it on
>
> --
> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Salz and Benjamin for your feedback. Indeed my Wireshark version was
unable to decode TLS 1.3. I got an update from the shared link.

I had one doubt about the server side session caching. I read that server
side server caching is disabled by default. Then, how is session resumption
possible using session identifiers because that is is stateful resumption
as I have understood with servers maintaining the session info. Whereas
with session tickets, client maintains the session tickets.
I am getting confused on the session caching concept. Could someone please
clarify.

Also, for TLS 1.3, should the server caching be enabled for session
resumption ?

Thanks
BR,
Neetish

On Sat, Jun 10, 2017 at 7:09 AM, Salz, Rich  wrote:

> > It is quite likely that your version of wireshark does not know how to
> properly decode the TLS 1.3 ServerHello.
>
> Please see  https://www.ietf.org/mail-archive/web/tls/current/
> msg22333.html for information about downloading an early release of
> wireshark.
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Matt

On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell  wrote:

>
>
> On 08/06/17 23:12, Neetish Pathak wrote:
> > Thanks.
> > I had one query regarding the TLS 1.3 implementation on server side. I
> > have a simple client server program with session resumption working with
> > TLS 1.2.
> > When I use TLS 1.3, I see that server hello message has a malformed
> > packet.
>
> How do you know it is malformed? The format of the ServerHello message
> has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
> ServerHello then you will be surprised.
>


*I know the ServerHello is malformed from the WIRESHARK LOGS. It shows an
exception for the ServerHello with malformed packet message.*


>
> > Though the SSL handshake is successful. I am not observing
> > session resumption.
> > I want to know what causes server hello to have a malformed packet.
> > Also, is any extra configuration required for TLS 1.3 ?
> > I am assuming TLS 1.3 can also use session Ids/ tickets for session
> > resumption.
>
> You probably want to read this blog post:
>
> https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
>
> *This blogpost is highly useful. Thanks for directing me here. I
am following the guidelines.*


> Session ids are not used in TLSv1.3 and session tickets work very
> differently. Session resumption should work just fine but there are some
> things to be aware of (discussed in the blog post).
>
> Matt
>
>
> >
> > Thanks
> > Best Regards,
> > Neetish
> >
> > On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 08/06/17 01:26, Neetish Pathak wrote:
> > > Hello All,
> > >
> > > I am new to the Openssl community.
> > > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > > performance benchmarking. I wanted to know if the session ticket
> support
> > > for session resumption enabled;ed by default for OpenSSL TLS v 1.2
> or it
> > > needs to be explicitly enabled?
> >
> > It is on by default.
> >
> > Matt
> >
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> > <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> --
> 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 Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks.
I had one query regarding the TLS 1.3 implementation on server side. I have
a simple client server program with session resumption working with TLS
1.2.
When I use TLS 1.3, I see that server hello message has a malformed packet.
Though the SSL handshake is successful. I am not observing session
resumption.
I want to know what causes server hello to have a malformed packet. Also,
is any extra configuration required for TLS 1.3 ?
I am assuming TLS 1.3 can also use session Ids/ tickets for session
resumption.

Thanks
Best Regards,
Neetish

On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  wrote:

>
>
> On 08/06/17 01:26, Neetish Pathak wrote:
> > Hello All,
> >
> > I am new to the Openssl community.
> > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > performance benchmarking. I wanted to know if the session ticket support
> > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> > needs to be explicitly enabled?
>
> It is on by default.
>
> 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

[openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Hello All,

I am new to the Openssl community.
I am using the latest version of Openssl (with TLS 1.3 enabled) for
performance benchmarking. I wanted to know if the session ticket support
for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
needs to be explicitly enabled?

Thanks
Best regards,
Neetish
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users