RE: Race condition involving SSL_CTX_new

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: Race condition involving SSL_CTX_new

Takurou Saitou
Hi!

There is one point confirmation.

May I think the action on the trouble described in the following mail
was done with the E-mail of following openssl-cvs (Show with URL)?

http://marc.theaimsgroup.com/?l=openssl-cvs&m=109870286615557&w=2

I use the Openssl0.9.7d in our project.

Takurou Saitou.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Arnold Hendriks
> Sent: Monday, October 25, 2004 7:30 PM
> To: [hidden email]
> Subject: Race condition involving SSL_CTX_new
>
>
> Dear list,
>
> I've been using the openssl libs for quite some time, and so far
> they've always worked
> fine. Recently, I've had to change my code to use different contexts
> per connection
> (due to easier key management being available in the SSL_CTX family),
> and now I'm
> hitting a race condition when starting the openssl libraries
> (0.9.7d). Sporadically, the
> following error appears:
>
> SSL:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
>
> Scanning through the google archive I saw that this problem was known
> and that a fix
> was made, but the fix was incorrect. Firstly, load_ciphers is only
> called when
> init_ciphers is set to 1.
>
> But the first thing load_ciphers does is setting init_ciphers to 0 -
> a parallel running call
> to this code (quite likely on my SMP machine):
>
> if (init_ciphers)
> {
> CRYPTO_w_lock(CRYPTO_LOCK_SSL);
> if (init_ciphers) load_ciphers();
> CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
> }
>
> will cause the second thread to skip load_ciphers, and thus continue
> running without
> having a completed init_ciphers call.
>
> Moving the init_ciphers=0; statement to the end of load_ciphers would
> fix that
> problem, but would probably open up an even subtler race condition:
> DCL may not be
> safe on all platforms without proper memory barriers. It would
> probably be safer to
> remove this 'optimization' all together: SSL_CTX_new does a lot of memory
> allocations already so the cost of hitting one more mutex should be
> negligible?
>
> The following patch should fix the race condition in SSL_CTX_new:
>
> diff -ur openssl-0.9.7d-orig/ssl/ssl_ciph.c openssl-0.9.7d/ssl/ssl_ciph.c
> --- openssl-0.9.7d-orig/ssl/ssl_ciph.c  Mon Oct 25 11:53:33 2004
> +++ openssl-0.9.7d/ssl/ssl_ciph.c       Mon Oct 25 11:55:58 2004
> @@ -759,12 +759,9 @@
>          */
>         if (rule_str == NULL) return(NULL);
>  
> -       if (init_ciphers)
> -               {
> -               CRYPTO_w_lock(CRYPTO_LOCK_SSL);
> -               if (init_ciphers) load_ciphers();
> -               CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
> -               }
> +       CRYPTO_w_lock(CRYPTO_LOCK_SSL);
> +       if (init_ciphers) load_ciphers();
> +       CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
>  
>         /*
>          * To reduce the work to do we only want to process the compiled
>
>
> With this fix, I haven't been able to reproduce the race condition so far.
>
>
> With regards,
> Arnold Hendriks
>
> --
> Arnold Hendriks <[hidden email]>
> B-Lex Information Technologies <http://www.b-lex.com/>
> Postbus 545, 7500 AM Enschede, The Netherlands
>
> B-Lex: +31 (0)53 4836543  
> Mobile: +31 (0)6 51710159
> MSN: [hidden email]  
> ICQ: 86313731
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]