[openssl-users] Loading multiple private keys a certificates on server program
Neetish Pathak
npathak2 at ncsu.edu
Wed Jun 28 22:10:22 UTC 2017
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 <npathak2 at ncsu.edu> 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 <matt at openssl.org> 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 at ncsu.edu
>> > <mailto:npathak2 at ncsu.edu>> wrote:
>> >
>> >
>> >
>> > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <matt at openssl.org
>> > <mailto:matt at 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 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 at ncsu.edu <mailto:npathak2 at ncsu.edu>
>> > > <mailto:npathak2 at ncsu.edu <mailto:npathak2 at ncsu.edu>>> wrote:
>> > >
>> > > I Appreciate your response
>> > >
>> > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <
>> matt at openssl.org <mailto:matt at openssl.org>
>> > > <mailto:matt at openssl.org <mailto:matt at 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?
>> > >
>> > > 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 at openssl.org <mailto:matt at openssl.org>
>> > <mailto:matt at openssl.org <mailto:matt at openssl.org>>
>> > > > <mailto:matt at openssl.org <mailto:matt at openssl.org>
>> > <mailto:matt at openssl.org <mailto:matt at 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
>> > <matt at openssl.org <mailto:matt at openssl.org>
>> > <mailto:matt at openssl.org <mailto:matt at openssl.org>>
>> > > <mailto:matt at openssl.org <mailto:matt at openssl.org>
>> > <mailto:matt at openssl.org <mailto:matt at openssl.org>>>
>> > > > > <mailto:matt at openssl.org
>> > <mailto:matt at openssl.org> <mailto:matt at openssl.org
>> > <mailto:matt at openssl.org>>
>> > > <mailto:matt at openssl.org <mailto:matt at openssl.org>
>> > <mailto:matt at openssl.org <mailto:matt at 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 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/mailm
>> an/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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170628/b1377e9e/attachment-0001.html>
More information about the openssl-users
mailing list