Re: [openssl-users] Openssl FIPS 186-4 Patch

[murugesh pitchaiah]

Hi Jacob,

Thanks for looking into this.
This FIPS186-4 is not just about SHA. It basically about the key
generation parameters. Especially I am looking for RSA key generation
parameters wrt FIPS 186-4.

Thanks,
Murugesh P.


On 10/5/17, Jakob Bohm  wrote:
> On 05/10/2017 13:51, murugesh pitchaiah wrote:
>> Hi All,
>>
>> I am looking for the FIPS 186-4 patch. I see it is not yet implemented
>> in openssl FIPS 2.0
> I assume FIPS 186-4 is the updated SHA standard that adds the SHA-3
> specification.
>
> In that case, that would be something that OpenSSL would first add to the
> basic OpenSSL library (perhaps in version 1.1.x).
>
> Once that is working as secure and tested (but not government "validated"),
> OpenSSL could incorporate that into their upcoming FIPS-validation (which I
> guess will become the "FIPS module 3.0").
>
> The "FIPS validation" bureaucracy is such that even basic bug fixes are
> very
> expensive and time consuming to get approved, thus adding new algorithms or
> other new features inside the "boundary" of the FIPS module is not
> something
> done under normal circumstances, and certainly not just to add another
> algorithm that isn't used by many people yet to a FIPS module that is only
> used by the OpenSSL 1.0.x library that they are trying to discontinue.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> 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

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

>> You should avoid calls to RAND_poll altogether on Windows. Do so by
>> explicitly seeding the random number generator yourself.
>
> As a starting point, try something like this:
>
> -
> static ENGINE *rdrand;
>
> void init_prng(void) {
> /* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */
> OPENSSL_cpuid_setup();
> ENGINE_load_rdrand();
> rdrand = ENGINE_by_id("rdrand");
> if (rdrand) {
> int success = 0;
> if (ENGINE_init(rdrand)) {
> success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND);
> }
>
> /***
> Per OpenSSL wiki, call ENGINE_free here regardless of whether we're
> successfully using rdrand. The "functional reference" to rdrand will
> be released when we call ENGINE_finish.
> ***/
> ENGINE_free(rdrand);
> if (! success) ENGINE_finish(rdrand), rdrand = NULL;
> }
>
> if (!rdrand && !RAND_status()){
>   RAND_screen();   /* this isn't really emough entropy, but it's a start 
> */
>   if (!RAND_status()) {
>  RAND_poll();  /* try to gather additional entropy */
>   }
>}
> }
>
> void terminate_engines(void) {
>if (rdrand) ENGINE_finish(rdrand), rdrand = NULL;
>/* similarly for any other engines you use */
>ENGINE_cleanup();
> }
> -
>
> Call init_prng after your OpenSSL initialization code (e.g. after calling 
> OpenSSL_add_all_algorithms), and terminate_engines when you're done using 
> OpenSSL (e.g. just before process exit).
>
> Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen 
> is really not a very good idea; it may be OK on workstations, but rarely 
> provides much entropy on servers because they typically aren't doing much 
> screen output. And if you still need entropy after the RAND_screen call, 
> you'll end up in RAND_poll anyway. The alternative is to write your own code 
> that harvests entropy from some source (or sources).
>
> Other people may have better suggestions.

Headless servers without hw entropy sources are tough. In this case I
use hedging. I've got some patches somewhere for 1.0.1, but they won't
apply to 0.9.8.

Also see:

* When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities
and Hedging Deployed Cryptography,
http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf
* When Virtual is Harder than Real: Security Challenges in Virtual
Machine Based Computing Environments,
http://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jeffrey Walton
> Sent: Thursday, October 05, 2017 13:33
> To: Jason Qian; OpenSSL Users
> Subject: Re: [openssl-users] DH_generate_key Hangs
> 
> 
> You should avoid calls to RAND_poll altogether on Windows. Do so by
> explicitly seeding the random number generator yourself.

As a starting point, try something like this:

-
static ENGINE *rdrand;

void init_prng(void) {
/* Try to seed the PRNG with the Intel RDRAND on-chip PRNG */
OPENSSL_cpuid_setup();
ENGINE_load_rdrand();
rdrand = ENGINE_by_id("rdrand");
if (rdrand) {
int success = 0;
if (ENGINE_init(rdrand)) {
success = ENGINE_set_default(rdrand, ENGINE_METHOD_RAND);
}

/***
Per OpenSSL wiki, call ENGINE_free here regardless of whether we're
successfully using rdrand. The "functional reference" to rdrand will
be released when we call ENGINE_finish.
***/
ENGINE_free(rdrand);
if (! success) ENGINE_finish(rdrand), rdrand = NULL;
}

if (!rdrand && !RAND_status()){
  RAND_screen();   /* this isn't really emough entropy, but it's a start */
  if (!RAND_status()) {
 RAND_poll();  /* try to gather additional entropy */
  }
   }
}

void terminate_engines(void) {
   if (rdrand) ENGINE_finish(rdrand), rdrand = NULL;
   /* similarly for any other engines you use */
   ENGINE_cleanup();
}
-

Call init_prng after your OpenSSL initialization code (e.g. after calling 
OpenSSL_add_all_algorithms), and terminate_engines when you're done using 
OpenSSL (e.g. just before process exit).

Note that this code uses RAND_screen if RDRAND isn't available. RAND_screen is 
really not a very good idea; it may be OK on workstations, but rarely provides 
much entropy on servers because they typically aren't doing much screen output. 
And if you still need entropy after the RAND_screen call, you'll end up in 
RAND_poll anyway. The alternative is to write your own code that harvests 
entropy from some source (or sources).

Other people may have better suggestions.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] [ANN] M2Crypto 0.27.0

[Matěj Cepl]

M2Crypto is the most complete Python wrapper for OpenSSL
featuring RSA, DSA, DH, EC, HMACs, message digests, symmetric
ciphers; SSL functionality to implement clients and servers;
HTTPS extensions to Python’s httplib, urllib, and xmlrpclib;
unforgeable HMAC’ing AuthCookies for web session management;
FTP/TLS client and server; S/MIME. M2Crypto can also be used to
provide SSL for Twisted. Smartcards supported through the Engine
interface.

This is another less earth-shattering release (after 0.26.2 which
brought us OpenSSL 1.1.0 compatbility), one more step towards
Python 3 compatibility nirvana, still more cleanups and
accumulated bug fixes, which could be resolved before the big
python3 branch is merged.

The release is available on
https://pypi.python.org/pypi/M2Crypto/ and all communication with
the maintainer (that’s me) should go to
https://gitlab.com/m2crypto/m2crypto.

Talking about the python3 branch, ALL TESTS PASS on all Pythons
from 2.6, 2.7, 3.3 to 3.6!!!

Now is the time to test, help with review, and complain about
whatever is wrong! I will still keep API stable, but changes are
relatively large, so this is your opportunity to suggest whatever
substantial thing you don't like with M2Crypto. I may not make it
happen in 0.28 (which I expect to be Py3k-compatible release),
but for settling the dust down and cleanup I prepare already
0.29, which should include yet more acummulated merge requests
and bugfixes, this time ones which should be better served with
python 3 layer already happening.

Happy hacking!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
  
Quod fuimus, estis; quod sumus, vos eritis.


pgpLb1r0AI_td.pgp
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

More :

 The call stacks are from 1.0.1c when calling DH_generate_key.
 Is any fix in the latest version for this ?


Thanks
Jason



On Thu, Oct 5, 2017 at 3:53 PM, Jason Qian  wrote:

> We call DH_generate_key(DH *dh) and the RAND_poll() is called
> ssleay_rand_bytes
>
>
>   libeay32d.dll!RAND_poll()  Line 572 C
>   libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int
> num=128, int pseudo=0)  Line 395 C
>   libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char *
> buf=0x03318fe0, int num=128)  Line 536 + 0xf bytes C
>   libeay32d.dll!RAND_bytes(unsigned char * buf=0x03318fe0, int num=128)
> Line 164 + 0x10 bytes C
>   libeay32d.dll!bnrand(int pseudorand=0, bignum_st * rnd=0x03318518, int
> bits=1023, int top=0, int bottom=0)  Line 152 + 0xd bytes C
> > libeay32d.dll!BN_rand(bignum_st * rnd=0x03318518, int bits=1023, int
> top=0, int bottom=0)  Line 213 + 0x17 bytes C
>   libeay32d.dll!generate_key(dh_st * dh=0x03316a88)  Line 170 + 0x11 bytes
> C
>   libeay32d.dll!DH_generate_key(dh_st * dh=0x03316a88)  Line 84 + 0xf
> bytes C
>
> Thanks
> Jason
>
> On Thu, Oct 5, 2017 at 3:33 PM, Jeffrey Walton  wrote:
>
>> On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users
>>  wrote:
>> > Thanks Michael,
>> >
>> >   I saw a lot of discussion for this issue on,
>> >
>> >https://mta.openssl.org/pipermail/openssl-dev/2015-July/
>> 002210.html
>> >
>> >   Not sure if openSSL has a workaround or a patch ?
>> >
>> >
>> > It hangs on :
>> >
>> > libeay32.dll!RAND_poll() Line 523
>> >
>> > if (heap_first(,
>> >   hlist.th32ProcessID,
>> >   hlist.th32HeapID))
>>
>> You should avoid calls to RAND_poll altogether on Windows. Do so by
>> explicitly seeding the random number generator yourself.
>>
>> Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues
>> on the OpenSSL wiki.
>>
>> Jeff
>>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

We call DH_generate_key(DH *dh) and the RAND_poll() is called
ssleay_rand_bytes


  libeay32d.dll!RAND_poll()  Line 572 C
  libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int
num=128, int pseudo=0)  Line 395 C
  libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf=0x03318fe0,
int num=128)  Line 536 + 0xf bytes C
  libeay32d.dll!RAND_bytes(unsigned char * buf=0x03318fe0, int num=128)
Line 164 + 0x10 bytes C
  libeay32d.dll!bnrand(int pseudorand=0, bignum_st * rnd=0x03318518, int
bits=1023, int top=0, int bottom=0)  Line 152 + 0xd bytes C
> libeay32d.dll!BN_rand(bignum_st * rnd=0x03318518, int bits=1023, int
top=0, int bottom=0)  Line 213 + 0x17 bytes C
  libeay32d.dll!generate_key(dh_st * dh=0x03316a88)  Line 170 + 0x11 bytes C
  libeay32d.dll!DH_generate_key(dh_st * dh=0x03316a88)  Line 84 + 0xf bytes
C

Thanks
Jason

On Thu, Oct 5, 2017 at 3:33 PM, Jeffrey Walton  wrote:

> On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users
>  wrote:
> > Thanks Michael,
> >
> >   I saw a lot of discussion for this issue on,
> >
> >https://mta.openssl.org/pipermail/openssl-dev/2015-
> July/002210.html
> >
> >   Not sure if openSSL has a workaround or a patch ?
> >
> >
> > It hangs on :
> >
> > libeay32.dll!RAND_poll() Line 523
> >
> > if (heap_first(,
> >   hlist.th32ProcessID,
> >   hlist.th32HeapID))
>
> You should avoid calls to RAND_poll altogether on Windows. Do so by
> explicitly seeding the random number generator yourself.
>
> Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues
> on the OpenSSL wiki.
>
> Jeff
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users
 wrote:
> Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
> change

I believe it was fixed earlier than that. Also see
https://rt.openssl.org/Ticket/Display.html?id=2100=guest=guest

As Michael suggested, 0.9.8 is the biggest problem. You should
probably solve that problem first.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jeffrey Walton]

On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users
 wrote:
> Thanks Michael,
>
>   I saw a lot of discussion for this issue on,
>
>https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html
>
>   Not sure if openSSL has a workaround or a patch ?
>
>
> It hangs on :
>
> libeay32.dll!RAND_poll() Line 523
>
> if (heap_first(,
>   hlist.th32ProcessID,
>   hlist.th32HeapID))

You should avoid calls to RAND_poll altogether on Windows. Do so by
explicitly seeding the random number generator yourself.

Also see https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues
on the OpenSSL wiki.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Salz, Rich via openssl-users]

  *   Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no 
change

Sorry, then try 1.1.0  The HEAPWALK bug/issue is fixed there.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
change


Thanks


On Thu, Oct 5, 2017 at 2:59 PM, Salz, Rich  wrote:

> You could try to backport the win_rand file from a more recent release.
>
>
>
> Far better, as Michael first said, to move to 1.0.2 or later.
>
>
>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Salz, Rich via openssl-users]

You could try to backport the win_rand file from a more recent release.

Far better, as Michael first said, to move to 1.0.2 or later.


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

Thanks Michael,

  I saw a lot of discussion for this issue on,

   https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html

  Not sure if openSSL has a workaround or a patch ?


It hangs on :

*libeay32.dll!RAND_poll() Line 523  *

if (*heap_first*(,
  hlist.th32ProcessID,
  hlist.th32HeapID))



Jason


On Thu, Oct 5, 2017 at 11:59 AM, Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> As I speculated, it appears you're hanging in random-number generation,
> probably due to a blocking CPRNG that can't get the entropy it needs.
>
>
>
> This is an operating-system issue, and needs to be referred to your OS
> administrator.
>
>
>
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
>
>
>
> *From:* Jason Qian [mailto:jq...@tibco.com]
> *Sent:* Thursday, October 05, 2017 08:44
> *To:* Michael Wojcik
> *Cc:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] DH_generate_key Hangs
>
>
>
>
>
> Here is the stack trace :
>
>
>
>  libeay32.dll!RAND_poll  Normal
>
>  [External Code]
>
>
>
>  libeay32.dll!RAND_poll() Line 523
>
>  libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo)
> Line 395
>
>  libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num)
> Line 536
>
>
>
>
>
> Thanks
>
> Jason
>
>
>
>
>
>
>
> On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik <
> michael.woj...@microfocus.com> wrote:
>
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Jason Qian via openssl-users
> > Sent: Wednesday, September 27, 2017 07:00
> > To: openssl-users@openssl.org
> > Subject: [openssl-users] DH_generate_key Hangs
>
> > Need some help,  one of our application that hangs when calling
> > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded
> condition.
> > Not sure, if anyone know this issue ?
>
> The issue is running OpenSSL 0.9.8, which has not been supported since
> 2015.
>
> DH_generate_key can use an engine (at least in supported versions of
> OpenSSL - I no longer have any 0.9.8 code around to check), so we really
> can't say what it might be doing in your application. But if it's using the
> default OpenSSL implementation, then if your DH parameters don't already
> include a private key, you'll end up generating random numbers. That can
> hang, if OpenSSL is using a blocking CPRNG source such as /dev/random.
>
> But you haven't provided nearly enough information to do more than
> speculate.
>
> What you need to do:
>
> 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes
> and isn't an LTS release). There's really no point in proceeding unless you
> do so. Your application is broken if it's using 0.9.8.
>
> 2. If the problem still occurs, debug a hanging instance and find out
> where *exactly* it's hung.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Michael Wojcik]

As I speculated, it appears you're hanging in random-number generation, 
probably due to a blocking CPRNG that can't get the entropy it needs.

This is an operating-system issue, and needs to be referred to your OS 
administrator.

Michael Wojcik
Distinguished Engineer, Micro Focus



From: Jason Qian [mailto:jq...@tibco.com]
Sent: Thursday, October 05, 2017 08:44
To: Michael Wojcik
Cc: openssl-users@openssl.org
Subject: Re: [openssl-users] DH_generate_key Hangs


Here is the stack trace :

 libeay32.dll!RAND_poll  Normal
 [External Code]

 libeay32.dll!RAND_poll() Line 523
 libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo) Line 
395
 libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) Line 536


Thanks
Jason



On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik 
> wrote:
> From: openssl-users 
> [mailto:openssl-users-boun...@openssl.org]
>  On Behalf Of Jason Qian via openssl-users
> Sent: Wednesday, September 27, 2017 07:00
> To: openssl-users@openssl.org
> Subject: [openssl-users] DH_generate_key Hangs

> Need some help,  one of our application that hangs when calling
> DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded condition.
> Not sure, if anyone know this issue ?

The issue is running OpenSSL 0.9.8, which has not been supported since 2015.

DH_generate_key can use an engine (at least in supported versions of OpenSSL - 
I no longer have any 0.9.8 code around to check), so we really can't say what 
it might be doing in your application. But if it's using the default OpenSSL 
implementation, then if your DH parameters don't already include a private key, 
you'll end up generating random numbers. That can hang, if OpenSSL is using a 
blocking CPRNG source such as /dev/random.

But you haven't provided nearly enough information to do more than speculate.

What you need to do:

1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes and 
isn't an LTS release). There's really no point in proceeding unless you do so. 
Your application is broken if it's using 0.9.8.

2. If the problem still occurs, debug a hanging instance and find out where 
*exactly* it's hung.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl FIPS 186-4 Patch

[Jakob Bohm]

On 05/10/2017 13:51, murugesh pitchaiah wrote:

Hi All,

I am looking for the FIPS 186-4 patch. I see it is not yet implemented
in openssl FIPS 2.0

I assume FIPS 186-4 is the updated SHA standard that adds the SHA-3
specification.

In that case, that would be something that OpenSSL would first add to the
basic OpenSSL library (perhaps in version 1.1.x).

Once that is working as secure and tested (but not government "validated"),
OpenSSL could incorporate that into their upcoming FIPS-validation (which I
guess will become the "FIPS module 3.0").

The "FIPS validation" bureaucracy is such that even basic bug fixes are 
very

expensive and time consuming to get approved, thus adding new algorithms or
other new features inside the "boundary" of the FIPS module is not 
something

done under normal circumstances, and certainly not just to add another
algorithm that isn't used by many people yet to a FIPS module that is only
used by the OpenSSL 1.0.x library that they are trying to discontinue.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

Here is the stack trace :

 libeay32.dll!RAND_poll  Normal
 [External Code]

 libeay32.dll!RAND_poll() Line 523
 libeay32.dll!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo)
Line 395
 libeay32.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) Line
536


Thanks
Jason



On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Jason Qian via openssl-users
> > Sent: Wednesday, September 27, 2017 07:00
> > To: openssl-users@openssl.org
> > Subject: [openssl-users] DH_generate_key Hangs
>
> > Need some help,  one of our application that hangs when calling
> > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded
> condition.
> > Not sure, if anyone know this issue ?
>
> The issue is running OpenSSL 0.9.8, which has not been supported since
> 2015.
>
> DH_generate_key can use an engine (at least in supported versions of
> OpenSSL - I no longer have any 0.9.8 code around to check), so we really
> can't say what it might be doing in your application. But if it's using the
> default OpenSSL implementation, then if your DH parameters don't already
> include a private key, you'll end up generating random numbers. That can
> hang, if OpenSSL is using a blocking CPRNG source such as /dev/random.
>
> But you haven't provided nearly enough information to do more than
> speculate.
>
> What you need to do:
>
> 1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes
> and isn't an LTS release). There's really no point in proceeding unless you
> do so. Your application is broken if it's using 0.9.8.
>
> 2. If the problem still occurs, debug a hanging instance and find out
> where *exactly* it's hung.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Openssl FIPS 186-4 Patch

[murugesh pitchaiah]

Hi All,

I am looking for the FIPS 186-4 patch. I see it is not yet implemented
in openssl FIPS 2.0

I see many vendors have implemented their own fix for FIPS 186-4
compliance. I am looking for the patch which i can reuse. Looks like
redhat too has its own patch.

Kindly share any pointers for the (open license for reuse) patch for
FIPS 186-4 compliance.
I am using openssl FIPS ECP 2.0.16.

Thanks,
Murugesh P.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Graceful shutdown of TLS connection for blocking sockets

[mahesh gs]

Hi All,

I have query regarding the SSL_read on blocking socket. How to come out of
blocking SSL_read when we have to close the connection ?

As per the documentation SSL_read will only return if there is any data or
an error occurred.

 "If the underlying BIO is *blocking*, SSL_read() will only return, *once
the read operation has been finished or an error occurred,* except when a
renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur"

I am trying following methods

*method 1:*

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application.
Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is
dangerous as calling SSL_shutdown and SSL_read from different threads on
same context can lead to undefined behaviour.

*method 2:*

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application.
shutdown the underlying TCP socket using system command (shutdown
(socket_id, SHUT_WR)) that cause the SSL_read to unblock.
3) Thread - 1 unwind and close the TCP socket (using close(socket_id)).
thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by
thread - 2 for write operation. As per my understanding this violates the
TLS standard because of not sending out the close notify handshake.

How to ensure to come out of blocking SSL_read and initiate SSL_shutdown
from same thread?

Thanks,
Mahesh G S
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users