Re: (no subject)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 <npathak2@xxxxxxxx
> <mailto:npathak2@xxxxxxxx>> wrote:
> 
> 
> 
>     On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <matt@xxxxxxxxxxx
>     <mailto:matt@xxxxxxxxxxx>> 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 <npathak2@xxxxxxxx <mailto:npathak2@xxxxxxxx>
>         > <mailto:npathak2@xxxxxxxx <mailto:npathak2@xxxxxxxx>>> wrote:
>         >
>         >     I Appreciate your response
>         >
>         >     On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         >     <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> 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 <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>
>         >         > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>>> 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
>         <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>
>         >         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>>
>         >         >     > <mailto:matt@xxxxxxxxxxx
>         <mailto:matt@xxxxxxxxxxx> <mailto:matt@xxxxxxxxxxx
>         <mailto:matt@xxxxxxxxxxx>>
>         >         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>         <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>>>> 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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux