On Tue, Oct 20, 2015 at 03:00:42PM +0200, Christopher Faulet wrote: > Le 20/10/2015 14:41, Willy Tarreau a écrit : > >On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote: > >>Le 20/10/2015 14:07, Willy Tarreau a écrit : > >>>On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote: > >>>>Then my understanding is that we should instead proceed differently : > >>>> - the cert is generated. It gets a refcount = 1. > >>>> - we assign it to the SSL. Its refcount becomes two. > >>>> - we try to insert it into the tree. The tree will handle its freeing > >>>> using SSL_CTX_free() during eviction. > >>>> - if we can't insert into the tree because the tree is disabled, then > >>>> we have to call SSL_CTX_free() ourselves, then we'd rather do it > >>>> immediately. It will more closely mimmick the case where the cert > >>>> is added to the tree and immediately evicted by concurrent activity > >>>> on the cache. > >>>> - we never have to call SSL_CTX_free() during ssl_sock_close() > >>>> because > >>>> the SSL session only relies on openssl doing the right thing based > >>>> on > >>>> the refcount only. > >>>> - thus we never need to know how the cert was created since the > >>>> SSL_CTX_free() is either guaranteed or already done for generated > >>>> certs, and this protects other ones against any accidental call to > >>>> SSL_CTX_free() without having to track where the cert comes from. > >>> > >>>This patch does this, and based on my understanding of your explanations, > >>>it should do the right thing and be safe all the time. What's your > >>>opinion > >>>? > >>> > >> > >>Yes, it should work and it avoids keeping extra info on generated > >>certificates. Good idea ! > > > >Thanks. Do you have a easy reproducer for the issue with the certs ? > >I tried a little bit but probably didn't test the proper sequence. > > > > Of course. Here is a little config file: > > ################################################################ > global > tune.ssl.default-dh-param 2048 > daemon > > listen ssl_server > mode tcp > bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem > > timeout connect 5000 > timeout client 30000 > timeout server 30000 > > server srv A.B.C.D:80 > > ################################################################ > > You just need to generate 2 SSL certificates with 2 CN (here > srv1.test.com and srv2.test.com). > > Then, by doing SSL requests with the first CN, there is no problem. But > with the second CN, it should segfault on the 2nd request. > > openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK > openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK > > But, > > openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK > openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO
Marvellous, thank you :-) Willy
