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
|
On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell <matt@xxxxxxxxxxx> 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 <npathak2@xxxxxxxx
> <mailto:npathak2@xxxxxxxx>> wrote:
>
>
>
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <matt@xxxxxxxxxxx
> *1) For certificate sent from the server side, I am using*> <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.
>
>
> 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 > *3) Certificate request Message*
> on server side for sending the certificateRequest message. Please
> correct me ?
>
> 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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
