Re: [openssl-users] DH_generate_key Hangs

[Salz, Rich via openssl-users]

1.0.2 and 1.1.0, whatever the highest letter is, are the supported releases.


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

Re: [openssl-users] ca md too weak

[Fabrice Delente]

Thanks for your answer too, I had already seen this wiki page before
posting but I didn't find in it any info on how to do that; I'll look
into it again and try harder then.

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

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

On Fri, Oct 6, 2017 at 12:22 PM, Fabrice Delente  wrote:
> OK, I understand, thanks for your answer! I'll look into building
> openvpn 2.4.3 from source.

I believe you only have to set Fedora's security policy to allow MD5.
That is covered in the Fedora wiki page you were provided.

There's no need to download and build a new OpenSSL and OpenVPN.
However, if you to take that path, then see
https://stackoverflow.com/q/38985889/608639.

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

Re: [openssl-users] ca md too weak

[Fabrice Delente]

OK, I understand, thanks for your answer! I'll look into building
openvpn 2.4.3 from source.

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

Re: [openssl-users] ca md too weak

[Jan Just Keijser]

Hi,

On 06/10/17 17:26, Fabrice Delente wrote:

Hello,

Until two days ago I used OpenVPN to connect to my workplace, on a
non-security sensitive tunnel (just for convenience).

However, OpenSSL updated on my machine (Fedora 26), and now the
certificate is rejected:

Fri Oct  6 17:25:06 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on
Sep 26 2017
Fri Oct  6 17:25:06 2017 library versions: OpenSSL 1.1.0f-fips  25 May
2017, LZO 2.08
Fri Oct  6 17:25:06 2017 OpenSSL: error:140AB18E:SSL
routines:SSL_CTX_use_certificate:ca md too weak
Fri Oct  6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
Fri Oct  6 17:25:06 2017 Exiting due to fatal error

What solutions are there to this problem? Can I configure OpenSSL to
accept this certificate after all?



it's not openssl that changed, it's the way openvpn is built on Fedora:
- openvpn 2.4.3 was built and linked against openssl 1.0 , which 
supports MD5 signed certs

- openvpn 2.4.4 was built and linked against openssl 1.1, which does not

Best solution:
- upgrade your CA to use something that's actually secure
Second best:
- downgrade openvpn to 2.4.3 (and get openssl 1.0 support back).

HTH,

JJK

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

Re: [openssl-users] ca md too weak

[Jeffrey Walton]

> Until two days ago I used OpenVPN to connect to my workplace, on a
> non-security sensitive tunnel (just for convenience).
>
> However, OpenSSL updated on my machine (Fedora 26), and now the
> certificate is rejected:
>
> ...
> routines:SSL_CTX_use_certificate:ca md too weak
> Fri Oct  6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
> Fri Oct  6 17:25:06 2017 Exiting due to fatal error
>
> What solutions are there to this problem? Can I configure OpenSSL to
> accept this certificate after all?

https://fedoraproject.org/wiki/Changes/CryptoPolicy

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

[openssl-users] ca md too weak

[Fabrice Delente]

Hello,

Until two days ago I used OpenVPN to connect to my workplace, on a
non-security sensitive tunnel (just for convenience).

However, OpenSSL updated on my machine (Fedora 26), and now the
certificate is rejected:

Fri Oct  6 17:25:06 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on
Sep 26 2017
Fri Oct  6 17:25:06 2017 library versions: OpenSSL 1.1.0f-fips  25 May
2017, LZO 2.08
Fri Oct  6 17:25:06 2017 OpenSSL: error:140AB18E:SSL
routines:SSL_CTX_use_certificate:ca md too weak
Fri Oct  6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
Fri Oct  6 17:25:06 2017 Exiting due to fatal error

What solutions are there to this problem? Can I configure OpenSSL to
accept this certificate after all?

Thanks.

F. Delente
-- 
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]

Hi Salz,

 I have built the 1.1.0f  with vc10 ( have to move some header files)

 Is the OpenSSL 1.1.0f supported version ?


Thanks
Jason



On Thu, Oct 5, 2017 at 3:31 PM, Salz, Rich  wrote:

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

Hi Jeff,

Checked https://rt.openssl.org/Ticket/Display.html?id=2100=
guest=guest
 and it seems exactly the same issue I have. I have moved to 1.0.1c.

   One question is where can I find the patch ? I have the built
environment and I can build myself.

Thanks for the help
Jason

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

> 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

[Jason Qian via openssl-users]

Thanks,

On Fri, Oct 6, 2017 at 9:36 AM, Salz, Rich  wrote:

> Okay, you seem to be looking for an answer and there isn’t one.
>
>
>
> The release you are using has problems when it decided to walk the heap.
> The release you are using WILL NOT BE FIXED.
>
>
>
> Change your code, backport the fix, or move to a more modern release.
> Sorry, there is no other way.
>
>
>
>
>
-- 
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]

Okay, you seem to be looking for an answer and there isn’t one.

The release you are using has problems when it decided to walk the heap.  The 
release you are using WILL NOT BE FIXED.

Change your code, backport the fix, or move to a more modern release.  Sorry, 
there is no other way.


-- 
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 
> Jason Qian via openssl-users
> Sent: Friday, October 06, 2017 07:14

> The challenge is that,  we are not directly calling RAND_poll(). We just call 
> DH_generate_key for DH key. 
> From the following call stacks, you can see the RAND_poll() is triggered by 
> ssleay_rand_bytes.

RAND_poll is being called because the PRNG does not have enough entropy. Seed 
it with sufficient entropy first, and it won't be called by DH_generate_key.

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

[Jason Qian via openssl-users]

Thanks Jeff,

The challenge is that,  we are not directly calling RAND_poll(). We just
call *DH_generate_key* for DH key.
>From the following call stacks, you can see the RAND_poll() is triggered by
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

Jason


On Thu, Oct 5, 2017 at 7:52 PM, Jeffrey Walton  wrote:

> >> 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] Openssl FIPS 186-4 Patch

[Salz, Rich via openssl-users]

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

I do not know how you got the opinion that OpenSSL has 186-4 support. It does 
not.  Perhaps other people have written patches.  If you find them, ask them to 
share with us (

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

[openssl-users] Double free of session occurs in multithread program.

[共通基盤ＳＳＬ［業務ＩＤ］ / COMMONSSL，GYOUMU]

Hello,

I am using OpenSSL's API to create multithreaded programs.
Check the contents of the program in ssl_test.c.

I have the following two questions.
The purpose of the question is to create a program that does not cause double 
free.

Question 1. Is this program correct as a program without double free?

Question 2. Because this program is complicated, I want to make it a simple 
program.
   I want to easily create a program that does not cause double free.
   If you can create with this OpenSSL API different from this program, 
please tell us about API and usage.


I will explain this program.

It takes time to create a session each time communicate.
Therefore, this program reuses sessions.

If it set the references of the SSL_SESSION structure to 1 or higher, the 
session will not be released.
SSL_connect() creates a new session.
At this time, references are incremented with SSL_get1_session().
This will cause references to be greater than 1, so the session will not be 
freed.
Multiple threads will share this session on subsequent communications.

When the session expires, it is necessary to release the old session that was 
being reused.
SSL_SESSION_free() can free old sessions that were being reused.
When executing SSL_SESSION_free(), specify the address of the 
session(SSL_SESSION structure).

This program outputs a core dump when deleting the line of "/*add*/" in 
ssl_test.c.
The cause is to double free the address of the same session by two threads.

As a measure against this problem, I limit the old session to one release.
Therefore, flag (fs_isDelete) is set to 1 when the preceding thread releases 
the old session.
After that, the following thread does not release the old session because the 
flag (fs_isDelete) is 1.


I will explain the API that affects the references of the SSL_SESSION structure.

(1) SSL_set_session()
Create a session to reuse.
I will explain the references.
The references of the reusing session are incremented.

(2) SSL_connect()
If the session has not expired, we will use the session to reuse.
If the session has expired, we will create a new session.
I will explain the references.
If the session has not expired, references will not change.
If the session has expired, the references for the new session are 1.
If the session has expired, the references of the old session will be 
decremented.

(3) SSL_get1_session()
If the session has not expired, obtain the address of the session to reuse.
If the session has expired, we will get a new session.
I will explain the references.
If the session has not expired, the references of the session to be reused will 
increment.
If the session has expired, the references of the new session will increment.

(4) SSL_SESSION_free()
SSL_SESSION_free() can free old sessions that were being reused.
When executing SSL_SESSION_free(), specify the address of the session 
(SSL_SESSION structure).
I will explain the references.
The references of the old session are decremented.
If references is 0, old sessions are freed.
If references are already 0, double the address of the same session.


I will explain the sequence of double free.

I will explain the operation in single thread.

First, thread 0 creates a new session.

Thread 0
References for sessions to reuse SSL processing starts.
SSL_connect() -> (+1) (1)
SSL_get1_session() > (+1) (2)
SSL_free() > (-1) (1)
SSL processing is terminated.

After that, thread 1 reuses the session.
At this time, the session may expire.
In that case, SSL_SESSION_free() decrements the references of the old session.

Thread 1
References of old sessions that have expired SSL processing 
starts.
SSL_set_session() -> (+1) (2)
SSL_connect() -> (-1) (1)
SSL_SESSION_free() > (-1) (0)
SSL processing is terminated.

I will explain the operation in multithreading.

Thread 1, SSL_SESSION_free() decrements references for old sessions.
After that, thread 2 also decrements the references of the same session and 
double-releases it.

Thread 1 Thread 2
SSL processing starts. SSL processing starts.
 References of old sessions that have expired
SSL_set_session() -> (+1) (2)
 (+1) (3) <- SSL_set_session()
SSL_connect() -> (-1) (2)
 (-1) (1) <- SSL_connect()
SSL_SESSION_free() > (-1) (0)
 (-1) (-1) < SSL_SESSION_free() SSL processing is 
terminated. Doubles the address of the same session.


ssl_test.c
---
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#define MAX_SOCKET_COUNT  2
#define SOCKID_EMPTY 0

int localSocket[MAX_SOCKET_COUNT];
int currentSocketCount = 0;

char *g_premorthostname = "hoge";
char *g_pserver_port_no = "12345";

#define CERTIFICATEFILEPATH