haproxy doesn't get SIGUSR1

[任晓磊]

I'm using service_loadbalancer from kubernetes (
https://github.com/kubernetes/contrib/tree/master/service-loadbalancer ) .
This program would re-spawn haproxy when it found a change of upstream
endpoints.
When service_loadbalancer starts, it runs haproxy -sf $(cat pidfile)
several times very quickly, and on that moment, haproxy -sf doesn't take
effect, there were many haproxy processes left.

I ran strace on the new haproxy -sf , and ensured it did send a SIGUSR1 to
the old process indicated by pidfile.
I tried to send SIGUSR1, SIGTERM, SIGINT to the left haproxy processes
while strace-ing on them, but they did not get the signals. I checkec
/proc/PID/status file, the SigBlk line is fffc7bfa7a27. SIGKILL can
kill the old process.

I searched SIG_SETMASK in the source code, and found it in signal.c file.
Maybe you should remove SIGUSR1 from blocked_sig set in signal_init()
function?


inspected old process with gdb:
(gdb) where
#0 0x7f42b2916763 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1  0x004d47db in
_do_poll (p=0x73a5e0 , exp=1633798236) at src/ev_epoll.c:125
#2  0x0040a8ef in
run_poll_loop () at src/haproxy.c:1576
#3  0x0040b438 in main
(argc=8, argv=0x7fff4168bd08) at src/haproxy.c:1912
(gdb) print jobs
$1 = 4
(gdb) print stopping
$2 = 0

ls -l /proc/46/fd/
total 0
lrwx-- 1 root root 64 Dec 2 06:00 0 -> anon_inode:[eventpoll]
lrwx-- 1 root root 64 Dec 2 06:00 4 -> socket:[5699]
lrwx-- 1 root root 64 Dec 2 06:00 5 -> socket:[5700]
lrwx-- 1 root root 64 Dec 2 06:00 6 -> socket:[5701]
lrwx-- 1 root root 64 Dec 2 06:00 7 -> socket:[5702]

the process have four sockets, just same as the jobs variable

lsof -p 46 | grep 
haproxy 46 root 4u unix 0x88102014e900 0t0 5699 /tmp/haproxy.45.tmp
haproxy 46 root 5u IPv4 5700 0t0 TCP *:jetcmeserver (LISTEN)
haproxy 46 root 6u IPv4 5701 0t0 TCP *:http (LISTEN)
haproxy 46 root 7u IPv4 5702 0t0 TCP *:mysql (LISTEN)

inspected old process with strace:
Process 46 attached
epoll_wait(0, {}, 200, 1000) = 0
epoll_wait(0, {}, 200, 1000) = 0
epoll_wait(0, {}, 200, 1000) = 0
epoll_wait(0, {}, 200, 1000) = 0
..

I don't know when did it block SIGUSR1 .

heartbeat traffic with many instances

[ジョハンガル]

Hello,

After tests we got best performance with nbproc = 24 (on our setup).
However it induces non negligible heartbeat traffic (nbproc=24, on a bunch of 
haproxy loadbalancers, healthcheｃking hundreds of containers),

Is there a way for each machine to delegate their healthchecking to a single 
process?
If nothing currently exists by default is it theoretically possible to make it 
work through a LUA plugin?

Thanks for your consideration!

Best regards,
Johan Gall

[SPAM] 回复吴总

[施课长]

haproxy，您好：

施课长
2015-12-2

RE: SSLv2Hello is disabled

[Igor Cicimov]

On 02/12/2015 10:19 AM, "Lukas Tribus"  wrote:
>
> > On 02/12/2015 12:41 AM, "Cohen Galit"
> > mailto:galit.co...@xura.com>> wrote:
> > >
> > > Hello,
> > >
> > >
> > >
> > > When HAProxy 1.5.9 is trying to sample our servers with this
> > configuration: tcp-check connect port 50443 ssl
> > >
> > >
> > >
> > > Our servers returns an error:
> > >
> > >
> > >
> > > 2015-11-29 09:48:18,155 [StartPoint-IMAP-SSL-Worker(14)]
> > [e8d05153-267f-4378-9a97-5245391ffe26] [] ERROR
> > connection.SSLHandshakeStartPointListener
> > (SSLHandshakeStartPointListener.java:onFailure :80) - SSL/TLS handshake
> > failed with client identified by
> > /10.106.75.51:35892
>
> Do you authenticate the client and/or the server?
>
>
>
> > > javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> > You need to disable SSLv3 in haproxy
>
> We are talking about the SSLv2 hello format. Its not about SSLv2
> or SSLv3, its about the hello format.
Which can also be used by sslv3 clients  hence my comment.

>
> However, haproxy unconditionally sets SSL_OP_NO_SSLv2, which
> makes openssl not use the SSLv2 Hello, so I don't see why this would
> happen.
>
> I think the error message from Tomcat about the SSLv2Hello is irrelevant
> and misleading and you actually have a simple authentication problem.
>
>
>
> Regards,
>
> Lukas
>
>

RE: SSLv2Hello is disabled

[Lukas Tribus]

> On 02/12/2015 12:41 AM, "Cohen Galit"  
> mailto:galit.co...@xura.com>> wrote: 
> > 
> > Hello, 
> > 
> > 
> > 
> > When HAProxy 1.5.9 is trying to sample our servers with this  
> configuration: tcp-check connect port 50443 ssl 
> > 
> > 
> > 
> > Our servers returns an error: 
> > 
> > 
> > 
> > 2015-11-29 09:48:18,155 [StartPoint-IMAP-SSL-Worker(14)]  
> [e8d05153-267f-4378-9a97-5245391ffe26] [] ERROR  
> connection.SSLHandshakeStartPointListener  
> (SSLHandshakeStartPointListener.java:onFailure :80) - SSL/TLS handshake  
> failed with client identified by  
> /10.106.75.51:35892

Do you authenticate the client and/or the server?



> > javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
> You need to disable SSLv3 in haproxy

We are talking about the SSLv2 hello format. Its not about SSLv2
or SSLv3, its about the hello format.

However, haproxy unconditionally sets SSL_OP_NO_SSLv2, which
makes openssl not use the SSLv2 Hello, so I don't see why this would
happen.

I think the error message from Tomcat about the SSLv2Hello is irrelevant
and misleading and you actually have a simple authentication problem.



Regards,

Lukas

  

Re: SSLv2Hello is disabled

[Igor Cicimov]

On 02/12/2015 12:41 AM, "Cohen Galit"  wrote:
>
> Hello,
>
>
>
> When HAProxy 1.5.9 is trying to sample our servers with this
configuration: tcp-check connect port 50443 ssl
>
>
>
> Our servers returns an error:
>
>
>
> 2015-11-29 09:48:18,155 [StartPoint-IMAP-SSL-Worker(14)]
[e8d05153-267f-4378-9a97-5245391ffe26] [] ERROR
connection.SSLHandshakeStartPointListener
(SSLHandshakeStartPointListener.java:onFailure :80) - SSL/TLS handshake
failed with client identified by /10.106.75.51:35892
>
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled
>
>
>
>
>
> Please advice,
>
>
>
> Thanks,
You need to disable SSLv3 in haproxy or enable it on the imap side which
probably has only TLS support setup. I can't see option of setting the ssl
version in tcp-check connect so probably has to be done globaly in haproxy.

[SPAM] Un éclairage autonome avec style c'est possible avec Generations Lantern‏

[Le Pro Du Net]

Re: Two questions about lua

[joris dedieu]

2015-12-01 10:57 GMT+01:00 Thierry FOURNIER :
> On Mon, 30 Nov 2015 18:03:00 +0100
> joris dedieu  wrote:
>
>> Thanks Thierry, for your answers.
>>
>>
>> 2015-11-30 16:53 GMT+01:00 Thierry FOURNIER :
>> > On Mon, 30 Nov 2015 08:37:00 +0100
>> > joris dedieu  wrote:
>> >
>> >> Hi all,
>> >>
>> >> I started to drive into haproxy's lua interface. I produced a few code
>> >> that allows dnsbl lookup and it seems to work.
>> >>
>> >> First I have a C wrapper against the libc resolver..
>> >>
>> >> #include 
>> >> #include 
>> >> #include 
>> >> #include 
>> >> #include 
>> >>
>> >> #include 
>> >> #include 
>> >>
>> >> static int gethostbyname_wrapper(lua_State *L)
>> >> {
>> >> const char* query = luaL_checkstring(L, 1);
>> >> struct hostent *he;
>> >> if ((he = gethostbyname(query)) != NULL) {
>> >> const char *first_addr =
>> >> inet_ntoa(*(struct in_addr*)he->h_addr_list[0]);
>> >> lua_pushstring(L, first_addr);
>> >> return 1;
>> >> }
>> >> return 0;
>> >> }
>> >>
>> >> static const luaL_Reg sysdb_methods[] = {
>> >> {"gethostbyname", gethostbyname_wrapper},
>> >> {NULL, NULL}
>> >> };
>> >>
>> >> LUALIB_API int luaopen_sysdb(lua_State *L) {
>> >> luaL_newlib(L, sysdb_methods);
>> >> return 1;
>> >> }
>> >>
>> >> I have some doubts on the asyncness of libc operations but in other
>> >> side I don't want to reinvent the wheel. Should I prefer a resolver
>> >> implementation that uses lua socket ? As far as I tested libc seems to
>> >> do the job.
>> >
>> > Hello,
>> >
>> > I confirm your doubts: gethostbyname is synchronous and it is a
>> > blocking call. If your hostname resolution is in the /etc/hosts file,
>> > it blocks while reading file. It it is from DNS server, it blocks
>> > waiting for the server response (or worse: wainting for the timeout).
>> >
>> > So, this code seems to run, but your HAProxy will be not efficient
>> > because the entire haproxy process will be blocked during each
>> > resolution. For example: if your DNS fails after 3s timeout, during 3s,
>> > HAProxy doesn't process any data.
>> >
>> > Otherwise, your code is the good way to perform fast Lua/C libraries.
>> >
>> > There are no way to simulate blocking access out of the HAProxy core,
>> > all the functions writed for Lua must be non block.
>>
>> Ok, I will check for a non blocking solution (maybe lua socket + pack
>> / unpack in C) .
>
>
> This is an potential solution because the Lua Sockets (implemented in
> HAProxy) are non blocking. You cannot exploit the Lua socket from the C
> part, because the non blocking system can't throught 2 level of Lua/C.
>
> Maybe you can use the DNS protocol with and TCP/53 DNS server. With
> this solution, the DNS serveur already exists, and the TCP socket are
> already non block compliant.

I started to port lua-resty-dns (pure lua). TCP is not a problem as
it's known by all major resolvers and as far as I know require by the
standard.

>
> Note that HAProxy supports now the native DNS, maybe in the version 1.7
> the DNS will be repported in le Lua core.

It would be great. IMHO unless your are too hurry, DNS is a nice way
to distribute informations across a network. I already see tow usages
: dnsbl and googlebot^w crawler validation. But there should be more
usage.

Joris
>
>
>> >
>> >
>> >> Then the lua code
>> >>
>> >> local sysdb = require("sysdb")
>> >>
>> >> core.register_fetches("rbl", function(txn, rbl, ip)
>> >> if (not ip) then
>> >> ip = txn.sf:src()
>> >> end
>> >> if (not rbl) then
>> >> rbl = "zen.spamhaus.org"
>> >> end
>> >> local query = rbl
>> >> for x in string.gmatch(ip, "[^%.]+") do
>> >> query = x .. '.' .. query
>> >> end
>> >> if(sysdb.gethostbyname(query)) then
>> >> return 1
>> >> else
>> >> return 0
>> >> end
>> >> end)
>> >>
>> >> I want to use a sticky table as a local cache so my second question :
>> >> is there a way to set a gpt0 value from lua ?
>> >
>> >
>> > You can use the samples fetches mapper and use the sc_set_gpt0. The
>> > syntax is like this:
>> >
>> > For the read access:
>> >
>> >txn.sf:sc_set_gpt0()
>> >txn.sc:table_gpc0()
>> >
>> > For the write access, I don't have direct solution. You must use an Lua
>> > sample fetch and the following configuration directive:
>> >
>> >http-request sc-set-gpt0 lua.my_sample_fetch
>>
>> Yes that's an option.
>>
>> >
>> > Maybe it will be a good idea to implement the stick table access in Lua.
>> >
>> > If you want a other maneer to store shared data inhaproxy, you can use
>> > maps. The maps are shared by all the HAProxy process including Lua with
>> > a special API (see Map class)
>>
>>  I thought on Maps but I didn't find a write access  in lua according
>> to http://www.arpalert.org/src/haproxy-lua-api

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

Hi Dave,

On Tue, Dec 01, 2015 at 03:04:21PM +, Dave Zhu (yanbzhu) wrote:
> I apologize for not responding sooner, I was waiting for more comments before
> starting implementation, then this fell off my radar when other
> responsibilities picked up.

No problem, we're all in the same situation, don't worry!

> I???ve got some downtime and can start working on Willy???s proposal, if that
> will meet the requirements of the people here.

That would be awesome! That said, don't put yourself under pressure,
yes it's something that people would love to have but don't stop all
your activities for this. I tend to think that there are people
volunteering for testing here given the demand, so do not hesitate
to post preview patches as you did initially.

Cheers,
willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

I apologize for not responding sooner, I was waiting for more comments before 
starting implementation, then this fell off my radar when other 
responsibilities picked up.

I’ve got some downtime and can start working on Willy’s proposal, if that will 
meet the requirements of the people here.

-Dave

From: Olivier Doucet mailto:webmas...@ajeux.com>>
Date: Monday, November 30, 2015 at 6:32 PM
To: Willy Tarreau mailto:w...@1wt.eu>>
Cc: Yanbo Zhu mailto:yanb...@cisco.com>>, Emeric Brun 
mailto:eb...@haproxy.com>>, Lukas Tribus 
mailto:luky...@hotmail.com>>, Remi Gacogne 
mailto:rgaco...@coredump.fr>>, Nenad Merdanovic 
mailto:ni...@nimzo.info>>, 
"haproxy@formilux.org" 
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

Hello,

I'm digging out this thread, because having multiple certificate for one single 
domain (SNI) but with different key types (RSA/ECDSA) can really be a great 
functionality. Is there some progress ? How can we help ?

A subsidiary question is : how much ECDSA certificates are supported ? So if I 
use a single ECDSA certificate, how many people wont be able to see my content ?


Olivier


2015-08-25 18:16 GMT+02:00 Willy Tarreau mailto:w...@1wt.eu>>:
Hi Dave,

On Tue, Aug 25, 2015 at 03:50:23PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy,
>
> On 8/25/15, 10:36 AM, "Willy Tarreau" mailto:w...@1wt.eu>> wrote:
>
> >This means that the RSA/DSA/ECDSA cert names must be derived from the
> >original cert name.
>
> Iąve thought of a way to avoid this behavior, with the end result being
> very similar to what you/Emeric proposed.
>
> What if we delayed the creation of the SSL_CTX until we have all the certs
> specified by the config?

In my opinion that only adds extra burden because this delay adds loss of
knowledge or association between the certs that were initially loaded at
the same time.

> We would read in all the certificates first and
> store them based on the CN/SAN inside the cert, or the SNIs specified by
> the admin. We would also store the auxiliary information as well at this
> point. Your tree would look like:
>
>   Names -> Certificates + aux info
>
>
> We then iterate on all of the Names and create an SSL_CTX for each Name
> based on the certificates available + any wildcard/negation filters we
> have. This will fill out our FQDN tree. After creating the SSL_CTXąs we
> could free the original tree, as it would no longer be needed.
>
> In this scenario, each FQDN would have an SSL_CTX associated with it,
> which is a departure from the current model. While this may seem like a
> huge spike in memory footprint, consider that OpenSSL uses references for
> keys and certificates.

I'm not much concerned by this for now because when you have many FQDN,
you already have as many SSL_CTX today. I tend to consider that large
configs (the ones where memory footprint starts to matter) don't have
many names for each of their certs. For example the config that led to
crt-list being designed was working with 5 certificates. I really
doubt that there were more than 1-2 names per cert on average, I'd even
bet something around 1.01 or so in average.

> Therefore, the additional impact is limited to the
> extra pointers in SSL_CTX, instead of duplicating X509 or PKEY buffers. We
> could also add additional logic to search through the current FQDN tree
> for łduplicate˛ SSL_CTX that contain the same cert/keys, and just use the
> pointer instead of creating a new SSL_CTX. Given enough metadata around
> the SSL_CTX in the FQDN tree, this shouldnąt be too hard.

That's the part I tend to dislike. If we later add extra parameters in
crt-list, we'll be happy to keep each line separate and *not* to merge
them. The example of validity dates was one such case but there could
be other ones.

While this may seem a stupid or completely made up example, imagine that
we could specify on each line of the crt-list a filter on the source network
to decide if the cert has to be presented or not. This way users could
decide that certs signed with official CAs are delivered to the public
while certs signed with internal CAs are delivered inside. Or even just
to use different algos depending on the network, for example test ECDSA
just on internal users first. As long as we keep all the elements of one
crt-list entry tied together, all such fantasy remains possible. When we
tear them apart and only focus on names to pack everything together, this
is not possible anymore. You said yourself that the memory usage doesn't
matter much here, let's not risk to sacrify extensivity for the sake of
trying to compress just a few more bytes.

> I feel that this would solve the problem of admins having to keep track of
> the certificate names, and keep the current behavior of łLet HAProxy
> figure out the certs, hereąs a bunch of them˛.
>
> It would also solve the issue of conflicting names. For example:
>
> Cert A(RSA):
>
> CN: www.bl

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Julien Vehent]

On 2015-12-01 02:03, Willy Tarreau wrote:

On Mon, Nov 30, 2015 at 04:20:15PM -0800, Bryan Talbot wrote:

If your clients are all "modern" browsers and mobile devices, you're
probably good. If there are old clients, or other systems calling an 
API

there can be issues especially if they are using Java <= 7.


I recently stumbled on a site (which I forgot) which reported that 
about 75%
of their visitors support ECDSA. So in short, if we can divide the CPU 
usage
by 20 for 75% of the visitors, that's roughly a 3.5x performance 
improvement

to be expected, that would be nice!


For what it's worth, the next version of Mozilla's modern guidelines 
will most
likely prefer ECDSA certificates and only have ECDHE ciphers in the 
ciphersuite.


More testing is needed, but it seems that client support is mature 
enough.


https://github.com/mozilla/server-side-tls/pull/97

- Julien

SSLv2Hello is disabled

[Cohen Galit]

Hello,

When HAProxy 1.5.9 is trying to sample our servers with this configuration: 
tcp-check connect port 50443 ssl

Our servers returns an error:

2015-11-29 09:48:18,155 [StartPoint-IMAP-SSL-Worker(14)] 
[e8d05153-267f-4378-9a97-5245391ffe26] [] ERROR 
connection.SSLHandshakeStartPointListener 
(SSLHandshakeStartPointListener.java:onFailure :80) - SSL/TLS handshake failed 
with client identified by /10.106.75.51:35892
javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled


Please advice,

Thanks,

Galit Cohen
Comverse

"This e-mail message may contain confidential, commercial or privileged 
information that constitutes proprietary information of Xura, Inc. or its 
subsidiaries. If you are not the intended recipient of this message, you are 
hereby notified that any review, use or distribution of this information is 
absolutely prohibited and we request that you delete all copies and contact us 
by e-mailing to: secur...@xura.com. Thank You."

Re: Two questions about lua

[Thierry FOURNIER]

On Mon, 30 Nov 2015 18:03:00 +0100
joris dedieu  wrote:

> Thanks Thierry, for your answers.
> 
> 
> 2015-11-30 16:53 GMT+01:00 Thierry FOURNIER :
> > On Mon, 30 Nov 2015 08:37:00 +0100
> > joris dedieu  wrote:
> >
> >> Hi all,
> >>
> >> I started to drive into haproxy's lua interface. I produced a few code
> >> that allows dnsbl lookup and it seems to work.
> >>
> >> First I have a C wrapper against the libc resolver..
> >>
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >>
> >> #include 
> >> #include 
> >>
> >> static int gethostbyname_wrapper(lua_State *L)
> >> {
> >> const char* query = luaL_checkstring(L, 1);
> >> struct hostent *he;
> >> if ((he = gethostbyname(query)) != NULL) {
> >> const char *first_addr =
> >> inet_ntoa(*(struct in_addr*)he->h_addr_list[0]);
> >> lua_pushstring(L, first_addr);
> >> return 1;
> >> }
> >> return 0;
> >> }
> >>
> >> static const luaL_Reg sysdb_methods[] = {
> >> {"gethostbyname", gethostbyname_wrapper},
> >> {NULL, NULL}
> >> };
> >>
> >> LUALIB_API int luaopen_sysdb(lua_State *L) {
> >> luaL_newlib(L, sysdb_methods);
> >> return 1;
> >> }
> >>
> >> I have some doubts on the asyncness of libc operations but in other
> >> side I don't want to reinvent the wheel. Should I prefer a resolver
> >> implementation that uses lua socket ? As far as I tested libc seems to
> >> do the job.
> >
> > Hello,
> >
> > I confirm your doubts: gethostbyname is synchronous and it is a
> > blocking call. If your hostname resolution is in the /etc/hosts file,
> > it blocks while reading file. It it is from DNS server, it blocks
> > waiting for the server response (or worse: wainting for the timeout).
> >
> > So, this code seems to run, but your HAProxy will be not efficient
> > because the entire haproxy process will be blocked during each
> > resolution. For example: if your DNS fails after 3s timeout, during 3s,
> > HAProxy doesn't process any data.
> >
> > Otherwise, your code is the good way to perform fast Lua/C libraries.
> >
> > There are no way to simulate blocking access out of the HAProxy core,
> > all the functions writed for Lua must be non block.
> 
> Ok, I will check for a non blocking solution (maybe lua socket + pack
> / unpack in C) .


This is an potential solution because the Lua Sockets (implemented in
HAProxy) are non blocking. You cannot exploit the Lua socket from the C
part, because the non blocking system can't throught 2 level of Lua/C.

Maybe you can use the DNS protocol with and TCP/53 DNS server. With
this solution, the DNS serveur already exists, and the TCP socket are
already non block compliant.

Note that HAProxy supports now the native DNS, maybe in the version 1.7
the DNS will be repported in le Lua core.


> >
> >
> >> Then the lua code
> >>
> >> local sysdb = require("sysdb")
> >>
> >> core.register_fetches("rbl", function(txn, rbl, ip)
> >> if (not ip) then
> >> ip = txn.sf:src()
> >> end
> >> if (not rbl) then
> >> rbl = "zen.spamhaus.org"
> >> end
> >> local query = rbl
> >> for x in string.gmatch(ip, "[^%.]+") do
> >> query = x .. '.' .. query
> >> end
> >> if(sysdb.gethostbyname(query)) then
> >> return 1
> >> else
> >> return 0
> >> end
> >> end)
> >>
> >> I want to use a sticky table as a local cache so my second question :
> >> is there a way to set a gpt0 value from lua ?
> >
> >
> > You can use the samples fetches mapper and use the sc_set_gpt0. The
> > syntax is like this:
> >
> > For the read access:
> >
> >txn.sf:sc_set_gpt0()
> >txn.sc:table_gpc0()
> >
> > For the write access, I don't have direct solution. You must use an Lua
> > sample fetch and the following configuration directive:
> >
> >http-request sc-set-gpt0 lua.my_sample_fetch
> 
> Yes that's an option.
> 
> >
> > Maybe it will be a good idea to implement the stick table access in Lua.
> >
> > If you want a other maneer to store shared data inhaproxy, you can use
> > maps. The maps are shared by all the HAProxy process including Lua with
> > a special API (see Map class)
> 
>  I thought on Maps but I didn't find a write access  in lua according
> to http://www.arpalert.org/src/haproxy-lua-api/1.6/index.html#map-class
> and some of my experiments


You're absolutely right. I'm afraid that I forgot to implement the
write acces. Maybe I had a good reason to not implement this, but I'm
not remember.

I will look for this.


Thierry


> Thanks
> Joris
> >
> > Thierry

[no subject]

[a...@a.yuanxin360.com]

E����~�&�]接m�桩G臣]4���4C�栽�{P�sm5�^粲��油4
�^N绲
�6�^u�Mt腠<�Ak�f�k+��н��f�k+��н��d���k��j�枨'璁hセ+�乾报 
=醋�v�]{�]:篆v�M舒��)麟G(�s�W��fj)z�M醋m��W��*'�@��拽�<�z妆氟ej)z

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Nenad Merdanovic]

Hello Oliver,

On 12/1/2015 12:32 AM, Olivier Doucet wrote:
> Hello,
> 
> I'm digging out this thread, because having multiple certificate for one
> single domain (SNI) but with different key types (RSA/ECDSA) can really
> be a great functionality. Is there some progress ? How can we help ?
> 

In the mean time, you can use this:
http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/

> A subsidiary question is : how much ECDSA certificates are supported ?
> So if I use a single ECDSA certificate, how many people wont be able to
> see my content ?

On a fairly busy site (couple tens of millions requests per day),
roughly 85% of the clients have been found ECDSA capable.

Regards,
Nenad

> 
> 
> Olivier
> 
> 
> 2015-08-25 18:16 GMT+02:00 Willy Tarreau mailto:w...@1wt.eu>>:
> 
> Hi Dave,
> 
> On Tue, Aug 25, 2015 at 03:50:23PM +, Dave Zhu (yanbzhu) wrote:
> > Hey Willy,
> >
> > On 8/25/15, 10:36 AM, "Willy Tarreau"  > wrote:
> >
> > >This means that the RSA/DSA/ECDSA cert names must be derived from the
> > >original cert name.
> >
> > Iąve thought of a way to avoid this behavior, with the end result
> being
> > very similar to what you/Emeric proposed.
> >
> > What if we delayed the creation of the SSL_CTX until we have all the 
> certs
> > specified by the config?
> 
> In my opinion that only adds extra burden because this delay adds
> loss of
> knowledge or association between the certs that were initially loaded at
> the same time.
> 
> > We would read in all the certificates first and
> > store them based on the CN/SAN inside the cert, or the SNIs specified by
> > the admin. We would also store the auxiliary information as well at this
> > point. Your tree would look like:
> >
> >   Names -> Certificates + aux info
> >
> >
> > We then iterate on all of the Names and create an SSL_CTX for each Name
> > based on the certificates available + any wildcard/negation filters we
> > have. This will fill out our FQDN tree. After creating the
> SSL_CTXąs we
> > could free the original tree, as it would no longer be needed.
> >
> > In this scenario, each FQDN would have an SSL_CTX associated with it,
> > which is a departure from the current model. While this may seem like a
> > huge spike in memory footprint, consider that OpenSSL uses references 
> for
> > keys and certificates.
> 
> I'm not much concerned by this for now because when you have many FQDN,
> you already have as many SSL_CTX today. I tend to consider that large
> configs (the ones where memory footprint starts to matter) don't have
> many names for each of their certs. For example the config that led to
> crt-list being designed was working with 5 certificates. I really
> doubt that there were more than 1-2 names per cert on average, I'd even
> bet something around 1.01 or so in average.
> 
> > Therefore, the additional impact is limited to the
> > extra pointers in SSL_CTX, instead of duplicating X509 or PKEY buffers. 
> We
> > could also add additional logic to search through the current FQDN tree
> > for łduplicate˛ SSL_CTX that contain the same cert/keys, and just
> use the
> > pointer instead of creating a new SSL_CTX. Given enough metadata around
> > the SSL_CTX in the FQDN tree, this shouldnąt be too hard.
> 
> That's the part I tend to dislike. If we later add extra parameters in
> crt-list, we'll be happy to keep each line separate and *not* to merge
> them. The example of validity dates was one such case but there could
> be other ones.
> 
> While this may seem a stupid or completely made up example, imagine that
> we could specify on each line of the crt-list a filter on the source
> network
> to decide if the cert has to be presented or not. This way users could
> decide that certs signed with official CAs are delivered to the public
> while certs signed with internal CAs are delivered inside. Or even just
> to use different algos depending on the network, for example test ECDSA
> just on internal users first. As long as we keep all the elements of one
> crt-list entry tied together, all such fantasy remains possible. When we
> tear them apart and only focus on names to pack everything together,
> this
> is not possible anymore. You said yourself that the memory usage doesn't
> matter much here, let's not risk to sacrify extensivity for the sake of
> trying to compress just a few more bytes.
> 
> > I feel that this would solve the problem of admins having to keep track 
> of
> > the certificate names, and keep the current behavior of łLet HAProxy
> > figure out the certs, hereąs a bunch of them˛.
> >
> > It would also solve the issue of conflicting names. For example:
>