Re: openssl-1.1 SNI callback causing client failures

ERT_FATAL : - SSL_TLSEXT_ERR_ALERT_WARNING); + SSL_TLSEXT_ERR_OK); } /* switch ctx */ thanks, roberto > On Feb 17, 2017, at 10:22 AM, Emmanuel Hocdet <m...@gandi.net> wrote: > > Hi Roberto > >> Le 17 févr. 2017 à 01:27, Roberto Guimaraes <rguimar...@fa

bug: SSL_SESSION_set1_id shctx_new_cb produces undefined behavior

while the compat implementation of SSL_SESSION_st1_id and SSL_SESSION_st1_id_context calls merely assign the values, openssl-1.1.x will do a memcpy of the id pointer, which in err: clause of shctx_new_cb will have undefined behavior. this is a one liner in openssl (I will be sending it

openssl-1.1 SNI callback causing client failures

greetings, just a heads up that we’ve seen client breakage when using haproxy with openssl-1.1 — dunno how far along you are concerning ossl1.1 usage, but it has become very clear that openssl-1.1 behaves differently in a number of ways esp SNI callback. so, openssl-1.0.x does not actually

Re: [PATCH] BUG/MINOR: ssl: fix potential memory leak in ssl_sock_load_dh_params()

); return ret; } so I think the DH_free is indeed correct since it will leak otherwise. however, sometime along the way the destructor was added which will double-free the global variable. once again, apologize for the bug. thanks, roberto > On Jul 12, 2016, at 2:55 PM, Roberto Guimar

Re: [PATCH] BUG/MINOR: ssl: fix potential memory leak in ssl_sock_load_dh_params()

itself detect an use after free? I guess it doesn’t matter as it’s safer to just revert it. > On Jul 12, 2016, at 2:31 PM, Willy Tarreau <w...@1wt.eu> wrote: > > On Tue, Jul 12, 2016 at 02:11:39PM -0700, Roberto Guimaraes wrote: >> My apologies and thanks for the heads up! I wil

Re: [PATCH] BUG/MINOR: ssl: fix potential memory leak in ssl_sock_load_dh_params()

My apologies and thanks for the heads up! I will revert it on my end as well. Weird, nginx seems to have the same unconditional DH_free in there. roberto > On Jul 12, 2016, at 2:49 AM, Willy Tarreau wrote: > > On Sat, Jul 02, 2016 at 04:47:57PM +0200, Remi Gacogne wrote: >> I've

[PATCH] BUG/MINOR: ssl: fix potential memory leak in ssl_sock_load_dh_params()

Valgrind reports that the memory allocated in ssl_get_dh_1024() was leaking. Upon further inspection of openssl code, it seems that SSL_CTX_set_tmp_dh makes a copy of the data, so calling DH_free afterwards makes sense. thanks, roberto --- src/ssl_sock.c | 1 + 1 file changed, 1 insertion(+)

Re: possible minor memory leak in ssl_get_dh_1024

Willy Tarreau 1wt.eu> writes: > > Hi Roberto, > > Thanks. You're using git, so please check the CONTRIBUTING file to see > how to send your patch, you'll make both your work and ours easier > > Cheers, > Willy > > hello Willy, Sure I will send the patch in a bit. thanks, roberto

Re: possible minor memory leak in ssl_get_dh_1024

Roberto Guimaraes <rguimaraes@...> writes: > > seems like set_tmp_dh() performs its own allocation. So, it should be > OK to dh_free immediately after calling the setter. > Not sure the intention was to reuse the allocated local_dh_1024, > but that's not being done eithe

possible minor memory leak in ssl_get_dh_1024

seems like set_tmp_dh() performs its own allocation. So, it should be OK to dh_free immediately after calling the setter. Not sure the intention was to reuse the allocated local_dh_1024, but that's not being done either. index 5200069..7c17c9a 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@

Re: sni lookup precedence order - delay default cert insertion

Lukas Tribus <lukyt@...> writes: > > Hi, > > Am 05.05.2016 um 20:13 schrieb Roberto Guimaraes: > > First we have a fundamental disagreement in that you are saying > > haproxy does not implement a fallback cert: it may not explicitly > > implement one, but t

Re: sni lookup precedence order - delay default cert insertion

Lukas Tribus <lukyt@...> writes: > > Hi, > > Am 04.05.2016 um 01:46 schrieb Roberto Guimaraes: > > * couldn't access the page for a couple of days. > > > > crt-list did not help too much because we use dirs and it > > forces us to be explicit (

Re: sni lookup precedence order - delay default cert insertion

Lukas Tribus <lukyt@...> writes: > > Hi Roberto, > > Am 27.04.2016 um 20:21 schrieb Roberto Guimaraes: > > > > Hi Lukas, > > > > thanks for the reply and apologize for not being as thorough in my > > original post. > > Tend to focus

Re: sni lookup precedence order - delay default cert insertion

Lukas Tribus writes: > > Hi Roberto, > > I'm not quite sure what you are describing: > > > > > ex: > > bind . crt foo-san.com foo.com > > > > with both cotnaining *.foo.com > > > > foo-san.com would be the cert served. > > Same for fqdn collisions. > > You are talking about a

Re: sni lookup precedence order - delay default cert insertion

Lukas Tribus writes: > > Hi Roberto, > > I'm not quite sure what you are describing: > > > > > ex: > > bind . crt foo-san.com foo.com > > > > with both cotnaining *.foo.com > > > > foo-san.com would be the cert served. > > Same for fqdn collisions. > > You are talking about a

sni lookup precedence order - delay default cert insertion

Hi, Not sure if valid, and even if so, it might be minor and related to specific use cases. So, I've noticed that if in the same bind line we have a fallback cert followed by more specific certs, or a directory containing those certs, haproxy still adds the hosts of the fallback cert first,