(no subject)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

(no subject)

neetish
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 <[hidden email]> wrote:


On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I Appreciate your response
>
>     On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>
>         > <mailto:[hidden email] <mailto:[hidden email]>>> 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 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>         >     > <mailto:[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>> 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 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.
>         >
>         >     If you are on a local machine I would not expect a
>         significant speed up
>         >     in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce
>         the number of
>         >     round-trips required in order to avoid unnecessary network
>         latency. If
>         >     you are on a local machine then there isn't any
>         significant network
>         >     latency anyway - so timings are presumably dominated by
>         the CPU
>         >     intensive tasks. You should make sure that you are
>         comparing like with
>         >     like, i.e. the same ciphers, key lengths, key exchange
>         algorithms,
>         >     curves etc between TLSv1.2 and TLSv1.3. Differences in any
>         one of these
>         >     could obviously have significant performance impacts.
>         >
>         >     Matt
>         >
>         >     --
>         >     openssl-users mailing list
>         >     To unsubscribe:
>         >     https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
>         >     <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
>         <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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: (no subject)

Matt Caswell-2


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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <[hidden email]
>     <mailto:[hidden email]>> 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 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 <[hidden email] <mailto:[hidden email]>
>         > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>         >
>         >     I Appreciate your response
>         >
>         >     On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <[hidden email] <mailto:[hidden email]>
>         >     <mailto:[hidden email] <mailto:[hidden email]>>> 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 <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>         >         > <mailto:[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>> 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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>         >         <mailto:[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>
>         >         >     > <mailto:[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>
>         >         <mailto:[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>>> 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 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.
>         >         >
>         >         >     If you are on a local machine I would not expect a
>         >         significant speed up
>         >         >     in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed
>         to reduce
>         >         the number of
>         >         >     round-trips required in order to avoid
>         unnecessary network
>         >         latency. If
>         >         >     you are on a local machine then there isn't any
>         >         significant network
>         >         >     latency anyway - so timings are presumably
>         dominated by
>         >         the CPU
>         >         >     intensive tasks. You should make sure that you are
>         >         comparing like with
>         >         >     like, i.e. the same ciphers, key lengths, key
>         exchange
>         >         algorithms,
>         >         >     curves etc between TLSv1.2 and TLSv1.3.
>         Differences in any
>         >         one of these
>         >         >     could obviously have significant performance
>         impacts.
>         >         >
>         >         >     Matt
>         >         >
>         >         >     --
>         >         >     openssl-users mailing list
>         >         >     To unsubscribe:
>         >         >  
>          https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
>         >      
>          <https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>>
>         >         >  
>          <https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
>         >      
>          <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
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
>         >      
>          <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
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Loading...