Re: Integrating New Cipher Suite

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

 



Added a define in include/openssl/ssl.h:
   # define SSL_TXT_MYCIPHER       "MYCIPHER"

Integrated into ssl/s3_lib.c:
   static SSL_CIPHER ssl3_ciphers[] = {

   {
    1,
    TLS1_TXT_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
    TLS1_CK_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
    SSL_kECDHE,
    SSL_aECDSA,
    SSL_MYCIPHER,
    SSL_AEAD,
    TLS1_2_VERSION, TLS1_2_VERSION,
    DTLS1_2_VERSION, DTLS1_2_VERSION,
    SSL_HIGH | SSL_FIPS,
    SSL_HANDSHAKE_MAC_SHA384 | TLS1_PRF_SHA384,
    64,
    64,
   },
>That's a pretty small number of bits. Do you really mean it to be only 64?
>
>Does you ciphersuite show up with cipher -s?
>
>It's possible it is being rejected because it has insufficient security. If
>the number of bits is really 64 you could try droppping the security level to
>0 to allow it.
>
>If that doesn't help enable trace support with enable-ssl-trace and then try
>the -trace command ot s_client/s_server and see if the new ciphersuites is
>sent in ClientHello
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
After some debugging (exactly as mentioned above) it appears that the cipher suite does not show up in the ClientHello using the s_client/s_server. I modified the cipher for testing to use 512 bits instead of 64 so that it is ranked highest.

Error server side:
SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:1979

Error Client side:
SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_s3.c:1469:SSL alert number 80

Any idea why the cipher would appear under the list of supported tls1.2 ciphers, yet it does not appear under the ClientHello even if specified with the -cipher option?

Thank you for any leads!
Rob


On 4/12/17 8:06 AM, openssl-users-request@xxxxxxxxxxx wrote:
Send openssl-users mailing list submissions to
	openssl-users@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
	openssl-users-request@xxxxxxxxxxx

You can reach the person managing the list at
	openssl-users-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Integrating New Cipher Suite (Dr. Stephen Henson)
   2. Re: RSA PKCS1 v2.1 - Multi-primes and RSASSA-PSS (Davy Souza)
   3.  Escaped Issuer/Subject (c.holper@xxxxxxx)
   4. Multithreading: Global locks causing bottleneck in parallel
      SSL_write calls (dipakgaigole)


----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Apr 2017 18:54:09 +0000
From: "Dr. Stephen Henson" <steve@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re:  Integrating New Cipher Suite
Message-ID: <20170411185409.GA23595@xxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Tue, Apr 11, 2017, Schmicker, Robert wrote:

Added a define in include/openssl/ssl.h:
   # define SSL_TXT_MYCIPHER       "MYCIPHER"

Integrated into ssl/s3_lib.c:
   static SSL_CIPHER ssl3_ciphers[] = {

   {
    1,
    TLS1_TXT_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
    TLS1_CK_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
    SSL_kECDHE,
    SSL_aECDSA,
    SSL_MYCIPHER,
    SSL_AEAD,
    TLS1_2_VERSION, TLS1_2_VERSION,
    DTLS1_2_VERSION, DTLS1_2_VERSION,
    SSL_HIGH | SSL_FIPS,
    SSL_HANDSHAKE_MAC_SHA384 | TLS1_PRF_SHA384,
    64,
    64,
   },
That's a pretty small number of bits. Do you really mean it to be only 64?

Does you ciphersuite show up with cipher -s?

It's possible it is being rejected because it has insufficient security. If
the number of bits is really 64 you could try droppping the security level to
0 to allow it.

If that doesn't help enable trace support with enable-ssl-trace and then try
the -trace command ot s_client/s_server and see if the new ciphersuites is
sent in ClientHello

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


------------------------------

Message: 2
Date: Tue, 11 Apr 2017 12:50:29 +0000
From: Davy Souza <davy.souza@xxxxxxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Subject: Re:  RSA PKCS1 v2.1 - Multi-primes and
	RSASSA-PSS
Message-ID:
	<CP2P152MB179454491F9BCC350F89E1FB8A000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
	
Content-Type: text/plain; charset="iso-8859-1"

In what context do you want to use it? For example CMS, certificates, TLS,
    general application code or via the command line?


It's a C++ embedded application for a POS.  One requirement is to use PKCS#1 v2.1 for RSA functions.


Davy Alves de Souza
Computer Scientist
Federal University of S?o Carlos, Sorocaba / SP - Brazil
________________________________
De: openssl-users <openssl-users-bounces@xxxxxxxxxxx> em nome de Dr. Stephen Henson <steve@xxxxxxxxxxx>
Enviado: segunda-feira, 10 de abril de 2017 10:46:26
Para: openssl-users@xxxxxxxxxxx
Assunto: Re:  RSA PKCS1 v2.1 - Multi-primes and RSASSA-PSS

On Wed, Apr 05, 2017, Davy Souza wrote:

Hi,


I'm using RSA, but I need to know if OpenSSL RSA implements PKCS#1 v2.1. I have the following questions:

   1) Does OpenSSL support multi-prime?

No.

   2) Does OpenSSL support RSASSA-PSS?

Yes.

   3) If so, how can I use it?

In what context do you want to use it? For example CMS, certificates, TLS,
general application code or via the command line?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
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/20170411/7e8a5420/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 12 Apr 2017 06:47:25 +0200
From: "c.holper@xxxxxxx" <c.holper@xxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject:   Escaped Issuer/Subject
Message-ID: <614474ba-574f-1df9-134a-91fa8c3eac1f@xxxxxxx>
Content-Type: text/plain; charset=utf-8; format=flowed

I thought about escaping regarding DN itself (LDAP DN).

https://www.ietf.org/rfc/rfc4514.txt

https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzahy/rzahyunderdn.htm

https://msdn.microsoft.com/en-us/library/aa366101%28v=vs.85%29.aspx

Best regards


------------------------------

Message: 4
Date: 12 Apr 2017 10:54:28 -0000
From: "dipakgaigole" <dipakgaigole@xxxxxxxxxxxxxx>
To: <openssl-users@xxxxxxxxxxx>
Subject:  Multithreading: Global locks causing
	bottleneck in parallel SSL_write calls
Message-ID: <20170412105428.2021.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hi,&nbsp;I have a windows multi-threaded SSL server application which handles each client request in a new thread. The Server handles different types of requests. One of the request type is like &ldquo;send file&rdquo; where server thread has to read a file from local filesystem and send the content to the client.Server configurations:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FIPS: Enabled&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSL Protocol: TLSv1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cipher: AES256-SHA&nbsp;It was observed that as the number of thread parallelism increases, the throughput decreases.To profile the server, I had recompiled the OpenSSL and FIPS source with debug symbol information. When run under a statistical profiler &ldquo;verysleepy&ldquo; (http://www.codersnotes.com/sleepy) points out below stack (hotspot
 ) which was consuming most of the time.###################################WaitForSingleObjectEx&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KERNELBASE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [unknown]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x7fefd2610dcCRYPTO_lock&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LIBEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\crypto\cryptlib.c 597&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xfb0bb26FIPS_lock&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
 sp;&nbsp; LIBEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\fips_src\openssl-fips-2.0.10\fips\utl\fips_lck.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 69&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xfceb291fips_drbg_bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LIBEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\fips_src\openssl-fips-2.0.10\fips\rand\fips_drbg_rand.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 86&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xfcfe868RAND_bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
 bsp;&nbsp;&nbsp;&nbsp;&nbsp; LIBEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\crypto\rand\rand_lib.c&nbsp;&nbsp;&nbsp; 159&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0xfc0dbe5tls1_enc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSLEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\ssl\t1_enc.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 786&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x3b6675cdo_ssl3_write&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSLEAY64&nbsp;&nbsp;&nbsp;&nbsp;&
 nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\ssl\s3_pkt.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1042&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x3b4c336ssl3_write_bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSLEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\ssl\s3_pkt.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 830&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x3b4baddssl3_write&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSLEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\ssl\s3_lib.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
 nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4404&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x3b4796cSSL_write&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSLEAY64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:\openssl_src\openssl-1.0.2f\ssl\ssl_lib.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1047&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x3b7a3e4###################################&nbsp;To check if this behavior can be seen outside of our code, I wrote a standalone multi threaded SSL server which performs same task as &ldquo;send file&rdquo;. And profiling of the standalone server also point out at the similar stack. So I was able to reproduced this behavior in standalone program.File size used: 340 MB&nbsp;To find out how the bottleneck varies with increasing the parallel thread count 
 in standalone SSL server program, I analyzed one thread behavior with different parallelism and here are the results:######################&ldquo;Parallel thread count&rdquo; &nbsp;-&gt; &nbsp;&ldquo;% of time spend in waiting for global lock&rdquo;1 -&gt; 1 %2 -&gt; 2 %5 -&gt; 5 %10 -&gt; 40 %15 -&gt; 46 %20 -&gt; 65 %25 -&gt; 68 %30 -&gt; 70 %######################&nbsp;After digging into the FIPS code found that there is a global lock around the random number generation code which is causing the bottleneck when multiple threads want to perform SSL_write operation in parallel.Code snippet from fips/rand/fips_drbg_rand.c:######################/* Since we only have one global PRNG used at any time in OpenSSL use a global* variable to store context.*/static DRBG_CTX ossl_dctx;&hellip;.&hellip;.static int fips_drbg_bytes(unsigned char *out, int count)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DRBG_CTX *dctx = &amp;ossl_dctx;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int rv = 0;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsigned char *adin = NULL;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size_t adinlen = 0;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRYPTO_w_lock(CRYPTO_LOCK_RAND);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &hellip;.&nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &hellip;.&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRYPTO_w_unlock(CRYPTO_LOCK_RAND);######################&nbsp;As comment from fips_drbg_rand.c says, do we really need to have one global PRNG at any time in OpenSSL? Does any
 one has any suggestion about how starvation (due to the global locks) of parallel SSL_write can be reduced? Any suggestions are welcome :)&nbsp;Thanks,Dipak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170412/70b473ef/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 29, Issue 13
*********************************************


-- 
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