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