On Tue, Jan 05, 2016 at 09:12:23PM +, Dave Zhu (yanbzhu) wrote:
> Sorry for the spam, just found another error.
>
> New patch attached.
Merged, thank you Dave!
Willy
Sorry for the spam, just found another error.
New patch attached.
-Dave
On 1/5/16, 12:56 PM, "Dave Zhu (yanbzhu)" wrote:
>Hey guys,
>
>Happy new year!
>
>I¹ve attached a patch to fix formatting issues in the doc for my section:
>
>Thanks!
>-Dave
>
>
>On 12/15/15, 1:13 AM, "Willy Tarreau" wrot
Hey guys,
Happy new year!
I¹ve attached a patch to fix formatting issues in the doc for my section:
Thanks!
-Dave
On 12/15/15, 1:13 AM, "Willy Tarreau" wrote:
>Hi Lukas,
>
>On Tue, Dec 15, 2015 at 01:44:18AM +0100, Lukas Tribus wrote:
>> Hey guys,
>>
>> thanks everyone involved in this con
Hi Lukas,
On Tue, Dec 15, 2015 at 01:44:18AM +0100, Lukas Tribus wrote:
> Hey guys,
>
> thanks everyone involved in this contribution!
>
> Been meaning to give the patch-set a run last week, but things
> came up last minute (as they always do). I hope I can spend
> some time with it shortly.
Co
Hey guys,
thanks everyone involved in this contribution!
Been meaning to give the patch-set a run last week, but things
came up last minute (as they always do). I hope I can spend
some time with it shortly.
> On which branches was this merged ? 1.5, 1.6 or both?
Its a new feature, its in the
Hello,
2015-12-14 23:31 GMT+01:00 Willy Tarreau :
> On Mon, Dec 14, 2015 at 08:16:33PM +, Dave Zhu (yanbzhu) wrote:
> > Thank you Willy and Emeric for their efforts in the design, and thanks to
> > everyone else for all your support and help in testing/debugging this
> > feature!
> >
> > I靶e
On Mon, Dec 14, 2015 at 08:16:33PM +, Dave Zhu (yanbzhu) wrote:
> Thank you Willy and Emeric for their efforts in the design, and thanks to
> everyone else for all your support and help in testing/debugging this
> feature!
>
> I¹ve attached the DOC patch to this message. Please take a look and
Thank you Willy and Emeric for their efforts in the design, and thanks to
everyone else for all your support and help in testing/debugging this
feature!
I¹ve attached the DOC patch to this message. Please take a look and let me
know if you see any errors in formatting that needs fixed.
-Dave
On
Hi guys,
On Thu, Dec 10, 2015 at 09:29:57PM +0100, Janusz Dziemidowicz wrote:
> 2015-12-10 21:14 GMT+01:00 Dave Zhu (yanbzhu) :
> > Finished OCSP portion. It???s in patch 5
> >
> > OCSP staple files will have to be in the same format: haproxy.pem.rsa.ocsp
> > and haproxy.pem.ecdsa.ocsp. They will
2015-12-10 21:14 GMT+01:00 Dave Zhu (yanbzhu) :
> Finished OCSP portion. It’s in patch 5
>
> OCSP staple files will have to be in the same format: haproxy.pem.rsa.ocsp
> and haproxy.pem.ecdsa.ocsp. They will get picked up when you load
> haproxy.pem in any of the supported methods.
>
> This patch i
Finished OCSP portion. It’s in patch 5
OCSP staple files will have to be in the same format: haproxy.pem.rsa.ocsp
and haproxy.pem.ecdsa.ocsp. They will get picked up when you load
haproxy.pem in any of the supported methods.
This patch is slightly bigger, as there was some refactoring that had to
On Wed, Dec 9, 2015 at 10:54 AM, Dave Zhu (yanbzhu)
wrote:
>
> I was able to add functionality for loading multiple certs when the crt
> bind option is a directory. That’s in patch 4. Patch 2 now contains 4, 5,
> and 6.
>
>
Still passing basic tests for me including the crt directory support.
Tha
Hey Willy,
On 12/8/15, 5:40 PM, "Willy Tarreau" wrote:
>>>I do think so. We'll just have to remerge 4, 5 and 6 into their
>>>respective
>> >patches (2 apparently) and we're good to go. If Emeric doesn't raise
>>any
>> >objection (apparently you addressed his concerns) I can merge all that
>> >my
On Tue, Dec 08, 2015 at 10:32:02PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy,
>
> On 12/8/15, 5:27 PM, "Willy Tarreau" wrote:
> >
> >In my opinion, these suffixes should be used only after the real cert
> >file name. So when you load "foobar.ecdsa", you should only consider
> >"foobar.ecdsa.oc
Hey Willy,
On 12/8/15, 5:27 PM, "Willy Tarreau" wrote:
>
>In my opinion, these suffixes should be used only after the real cert
>file name. So when you load "foobar.ecdsa", you should only consider
>"foobar.ecdsa.ocsp" and so on. And from what I remember, on the CLI
>we mention the cert name when
Hi Dave,
On Tue, Dec 08, 2015 at 09:12:58PM +, Dave Zhu (yanbzhu) wrote:
> There are also 2 issues here.
>
>
> 1. Loading certs from a directory doesn't process multiple certs at the
> same time. This I can fix with another patch to add that functionality
I didn't think about this one
o:luky...@hotmail.com>>, Remi Gacogne
mailto:rgaco...@coredump.fr>>, Nenad Merdanovic
mailto:ni...@nimzo.info>>,
"haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX s
On Tue, Dec 8, 2015 at 11:18 AM, Dave Zhu (yanbzhu)
wrote:
> Hey Bryan,
>
> I believe I have gotten to the bottom of the behavior that you are seeing:
>
>
>1. 0.9.8 client cannot connect to dual cert port: This was a bug on my
>part. I neglected to set a DHE keys for the SSL_CTX with mult
erdanovic
mailto:ni...@nimzo.info>>,
"haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>, Bryan Talbot
mailto:bryan.tal...@ijji.com>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
Glad you were able to get
.org>>, Bryan Talbot
mailto:bryan.tal...@ijji.com>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
Glad you were able to get to the bottom of the crash.
With the newest 5 patches, I'm still not seeing the behavior I am expecting. To
make my testing and e
Glad you were able to get to the bottom of the crash.
With the newest 5 patches, I'm still not seeing the behavior I am
expecting. To make my testing and expectations hopefully more clear, I've
pushed them to github (https://github.com/btalbot/dual-stack-test) From a
laptop with Vagrant installed
On Mon, Dec 07, 2015 at 08:48:53PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy
>
> On 12/7/15, 3:11 PM, "Willy Tarreau" wrote:
> >
> >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
> >*is*
> >bogus. strncpy() has no right to guess the destination size.
> >
> >I suspect th
Hey Willy
On 12/7/15, 3:11 PM, "Willy Tarreau" wrote:
>
>Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
>*is*
>bogus. strncpy() has no right to guess the destination size.
>
>I suspect that if you just do this it would work (prefix the array with
>'&'
>and use [0] :
>
>
On Mon, Dec 07, 2015 at 08:04:30PM +, Dave Zhu (yanbzhu) wrote:
> One more thing :)
>
> Out of curiosity, I changed the code as specified in that bugzilla from:
>
> strncpy((char *)s_kt->name.key, trash.str, i);
>
> To
>
> node = &s_kt->name;
> strncpy((char *)node->key, trash.str, i);
>
One more thing :)
Out of curiosity, I changed the code as specified in that bugzilla from:
strncpy((char *)s_kt->name.key, trash.str, i);
To
node = &s_kt->name;
strncpy((char *)node->key, trash.str, i);
And the code ran without an issue. I believe that this is the issue that
Bryan first saw,
Hey Willy,
On 12/7/15, 2:22 PM, "Willy Tarreau" wrote:
>I'm sorry but this is not acceptable. We're hiding a deeper bug somewhere.
>Strncpy() is used at other places in the code (a few I agree) and is used
>by *a lot* of programs, it's a basic building block. If it's broken in one
>version of gcc
Hi Dave,
On Mon, Dec 07, 2015 at 06:49:54PM +, Dave Zhu (yanbzhu) wrote:
> Bryan found an interesting bug in the code, which I??ve root caused to an
> optimization bug(?)/eccentricity in gcc 4.8.4.
I'm sorry but this is not acceptable. We're hiding a deeper bug somewhere.
Strncpy() is used at
Bryan found an interesting bug in the code, which I’ve root caused to an
optimization bug(?)/eccentricity in gcc 4.8.4.
Either way, I’ve fixed the error and have attached 2 more patches on top
of the 3 already provided. 0004 fixed the bug, and 0005 cleans up some of
the code.
I’m reposting all 5
haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot
mailto:bryan.tal...@ijji.com>> wrote:
On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu)
mailto:yanb...@cisco.com>> wrote:
Hey Bryan,
i
gt;>,
"haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot
mailto:bryan.tal...@ijji.com>> wrote:
On Fri, Dec 4, 20
mailto:yanb...@cisco.com>>,
"haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot
mailto:bryan.tal...@ijji.com>> w
On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot wrote:
> On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu)
> wrote:
>
>> Hey Bryan,
>> it’s strange that it’s always loading the ECC cert. I just tested the
>> code on my end and I’m not seeing this behavior.
>>
>>
> I see it on OSX, I'll test on Li
On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu)
wrote:
> Hey Bryan,
> it’s strange that it’s always loading the ECC cert. I just tested the code
> on my end and I’m not seeing this behavior.
>
>
I see it on OSX, I'll test on Linux today.
> Back to your original problem though, do the certs
y@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
Another odd thing is that both certs are loaded even if the ECC cert doesn't
have the proper name.
In my testing with a bind line of
bind :8443 ssl crt ./var/tls/localhost.pem
the ECC cert is l
Another odd thing is that both certs are loaded even if the ECC cert
doesn't have the proper name.
In my testing with a bind line of
bind :8443 ssl crt ./var/tls/localhost.pem
the ECC cert is loaded if it is in that directory no matter what the file
name is.
-Bryan
On Thu, Dec 3, 2015 at 2
On Thu, Dec 3, 2015 at 2:00 PM, Dave Zhu (yanbzhu)
wrote:
> Hey Bryan.
>
> I noticed that you gave HAProxy a directory. You have to give it the name
> of the cert instead of the directory.
>
> So your config should be:
>
> bind :8443 ssl crt ./var/tls/localhost.pem
>
>
>
I get the same behavio
t 4:45 PM
To: Yanbo Zhu mailto:yanb...@cisco.com>>
Cc: "haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
Hi Dave.
I've applied the patches but things are not w
Hi Dave.
I've applied the patches but things are not working as I expected. It could
be that my expectations are incorrect though. I'm expecting that with two
(ECC and RSA) self-signed testing certificates deployed with the haproxy
config shown below that ECC capable clients will connect and use t
On Thu, Dec 03, 2015 at 07:24:10PM +, Dave Zhu (yanbzhu) wrote:
> HAProxy will use the first ³crt² file that it loads as the default
> cert(represented by bind_conf->default_ctx).
>
> So, if you loaded multiple certs in one operation as your first cert,
> HAProxy will have to determine WHICH c
Hey Willy
On 12/3/15, 1:34 PM, "Willy Tarreau" wrote:
>
>I'm sorry but I'm missing something. In which case could we have the
>choice
>between multiple SSL_CTX ? My understanding is that if the SNI is not
>found
>in the list, we currenlty fall back to the default cert. Now the
>difference
>is su
Hi Dave,
On Thu, Dec 03, 2015 at 05:36:36PM +, Dave Zhu (yanbzhu) wrote:
> On 12/3/15, 1:40 AM, "Willy Tarreau" wrote:
>
> >I didn't understand what you meant with this last sentence, it sounds like
> >there could be multiple default contexts which are more or less randomly
> >chosen so that
Hey Emeric,
On 12/3/15, 9:56 AM, "Emeric Brun" wrote:
>
>But i notice some inconsistencies.
>
>Patch2 (crt conf keywoard):
>If the file without key extension is present, this file is loaded but
>also the multi_load is called.
>
>However in Patch3 (crt-list)
>If the file without key extension is
Hey Willy
On 12/3/15, 1:40 AM, "Willy Tarreau" wrote:
>I didn't understand what you meant with this last sentence, it sounds like
>there could be multiple default contexts which are more or less randomly
>chosen so that confuses me.
Sorry if that was confusing. I was merely trying to indicate t
Hey Emeric,
I’m in the process of cleaning up the patches, indentation and style so
I’ll post up another set to the mailing list as Willy suggested.
-Dave
On 12/3/15, 9:56 AM, "Emeric Brun" wrote:
>On 12/02/2015 08:17 PM, Dave Zhu (yanbzhu) wrote:
>> Hello all,
>>
>> I¹ve written up Willy and
On 12/02/2015 08:17 PM, Dave Zhu (yanbzhu) wrote:
> Hello all,
>
> I¹ve written up Willy and Emeric¹s proposal and it seems to test fine, at
> least from a functionality standpoint.
>
> I would appreciate it if interested parties would beat on this harder than
> I did to work out kinks.
>
> To r
Hi Dave,
On Wed, Dec 02, 2015 at 07:17:36PM +, Dave Zhu (yanbzhu) wrote:
> Hello all,
>
> I¹ve written up Willy and Emeric¹s proposal and it seems to test fine, at
> least from a functionality standpoint.
Thanks a lot for doing this work!
> I would appreciate it if interested parties would
Hello all,
I¹ve written up Willy and Emeric¹s proposal and it seems to test fine, at
least from a functionality standpoint.
I would appreciate it if interested parties would beat on this harder than
I did to work out kinks.
To recap for those that are new:
You can now specify as a crt or a crt
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,
t;, Remi Gacogne
mailto:rgaco...@coredump.fr>>, Nenad Merdanovic
mailto:ni...@nimzo.info>>,
"haproxy@formilux.org<mailto:haproxy@formilux.org>"
mailto:haproxy@formilux.org>>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching
Hello,
I'm
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
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
On Mon, Nov 30, 2015 at 04:20:15PM -0800, Bryan Talbot wrote:
> On Mon, Nov 30, 2015 at 3:32 PM, 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
On Mon, Nov 30, 2015 at 3:32 PM, 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 ?
>
I'd lov
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
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 th
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
Hey willy,
One small comment. As of openssl v1.0.2 it actually supports loading
multiple certificates with different chains. It requires calling
SSL_CTX_add0_chain_cert (or SSL_CTX_add1_chain_cert, the exact
difference can be found in the man page) instead of
SSL_CTX_add_extra_chain_cert. I'v
Hi guys,
Yesterday Emeric and I brainstormed on this subject in the office. Emeric
brought on the table some cases which couldn't be reliably covered anymore,
and proposed a slightly different approach which finally convinced me.
I'll try to summarize here our long conversation and we'd like to g
On 08/21/2015 08:08 PM, Emeric Brun wrote:
> Hey Dave,
>
>>> the SNI tree a certificate regardless the CN/SAN. It's dirty i know, but
>>> some people use it.
>>>
>>> You will also notice, reading 'ssl_sock_process_crt_file' that if we use
>>> sni_filter (so filter in crt-list), a new ssl_ctx is al
On 08/21/2015 08:08 PM, Emeric Brun wrote:
> Hey Dave,
>
>>> the SNI tree a certificate regardless the CN/SAN. It's dirty i know, but
>>> some people use it.
>>>
>>> You will also notice, reading 'ssl_sock_process_crt_file' that if we use
>>> sni_filter (so filter in crt-list), a new ssl_ctx is al
Hey Dave,
>> the SNI tree a certificate regardless the CN/SAN. It's dirty i know, but
>> some people use it.
>>
>> You will also notice, reading 'ssl_sock_process_crt_file' that if we use
>> sni_filter (so filter in crt-list), a new ssl_ctx is always allocated and
>> stored. But if no filter is se
On Fri, Aug 21, 2015 at 05:09:08PM +, Dave Zhu (yanbzhu) wrote:
> On 8/21/15, 1:07 PM, "Dave Zhu (yanbzhu)" wrote:
>
> >Hey Emeric,
> >
> >>I think you don't notice that certificate in the wild card tree are not
> >>stored using their fullnames (we exclude the '*' and start at the first
> >>'
On Fri, Aug 21, 2015 at 05:07:30PM +, Dave Zhu (yanbzhu) wrote:
> In the current model, these are added as SNI entries in the tree. But
> these entries won¹t ever be used if there is another SNI entry that was
> loaded before. So even though they are added to the tree, they wouldn¹t
> ever be u
On 8/21/15, 1:07 PM, "Dave Zhu (yanbzhu)" wrote:
>Hey Emeric,
>
>>I think you don't notice that certificate in the wild card tree are not
>>stored using their fullnames (we exclude the '*' and start at the first
>>'.').
>
>No I did not notice this, but I believe this is actually a good thing.
>Th
Hey Emeric,
>I think you don't notice that certificate in the wild card tree are not
>stored using their fullnames (we exclude the '*' and start at the first
>'.').
No I did not notice this, but I believe this is actually a good thing.
This way, crt-list entries with a filter will always get proc
Hey Dave,
>> The first proposal was very less intrusive (the ones which don't used
>> 1.0.2 API but secret callback). But i understand the point of view of the
>> experts of the mailing list .
>>
>> Did you expore an intermediate solution:
>>
>> Continue to load keys/certificates etc in one new al
Hey Emeric,
>>
>>
>> In 1.0.2, we can make use of API to load multiple certificate chains
>>into
>> a CTX. Prior to 1.0.2, you could not load the chains. So the checks
>>ensure
>> that we make use of the new APIs, and can then serve the correct
>> certificate to users based on the user¹s cipher
On 08/21/2015 03:51 PM, Dave Zhu (yanbzhu) wrote:
>
> Emeric,
>>
>> Code initially use 'ctx->default_passwd_callback_userdata' to allow us to
>> manage a further way to manage passphrase via configuration.
>
> As far as I could tell, this field was not getting set anywhere in the
> code. It¹s set
Hi,
I haven't had time to look at the entire patch set, so this is just some
remarks on the points that Emeric mentioned.
>> Code initially use 'ctx->default_passwd_callback_userdata' to allow us to
>> manage a further way to manage passphrase via configuration.
>
> As far as I could tell, this
Hey Willy
>
>FWIW, some users ask that we can load a cert's passphrase from a file,
>I was supposed to look at this but didn't have time, maybe the callback
>above would be what will be needed for this, though I have no idea yet.
>
>Willy
>
If that¹s the case, then we should definitely include t
Hi Dave,
On Fri, Aug 21, 2015 at 01:51:00PM +, Dave Zhu (yanbzhu) wrote:
> >Code initially use 'ctx->default_passwd_callback_userdata' to allow us to
> >manage a further way to manage passphrase via configuration.
>
> As far as I could tell, this field was not getting set anywhere in the
> co
Emeric,
>
>Code initially use 'ctx->default_passwd_callback_userdata' to allow us to
>manage a further way to manage passphrase via configuration.
As far as I could tell, this field was not getting set anywhere in the
code. It¹s set with SSL_CTX_set_default_passwd_cb, which I did not find in
the
On 08/21/2015 02:53 PM, Willy Tarreau wrote:
> Guys,
>
> I'm reviving this thread here. It turns out that Emeric had some concerns
> about possible impacts of the patch, maybe in part due to the openssl API
> though I'm not sure I understood everything right. I found it more efficient
> to involve
Guys,
I'm reviving this thread here. It turns out that Emeric had some concerns
about possible impacts of the patch, maybe in part due to the openssl API
though I'm not sure I understood everything right. I found it more efficient
to involve all people who expressed opinions in this thread so that
>
> I¹ve corrected the indentation to use tabs instead of spaces. Here¹s the
> new diff:
>
> Is there a better method to do code reviews other than using the mailing
> list? I¹ll use whatever is easiest for you guys.
>
> Again, sorry for the delayed response. I¹ll track the website from now on,
Hi Dave,
On Tue, Jul 14, 2015 at 03:38:47PM +, Dave Zhu (yanbzhu) wrote:
> >Emeric responded here:
> >http://marc.info/?l=haproxy&m=143643724320705&w=2
> >
> >Not sure what you mean by pushing this to master...?
> >
> >
> >
> >Lukas
> >
>
> I¹ve corrected the indentation to use tabs instead o
>Emeric responded here:
>http://marc.info/?l=haproxy&m=143643724320705&w=2
>
>Not sure what you mean by pushing this to master...?
>
>
>
>Lukas
>
I¹ve corrected the indentation to use tabs instead of spaces. Here¹s the
new diff:
Is there a better method to do code reviews other than using the mai
>
>Emeric responded here:
>http://marc.info/?l=haproxy&m=143643724320705&w=2
>
>Not sure what you mean by pushing this to master...?
>
>
>
>Lukas
>
I¹m so sorry for that. I did not get that email. Even though I am
subscribed to the list. IT must be filtering it somehow.
I¹ll use the website from
> Hey guys,
>
> I haven’t gotten any feedback for this feature. Unless there’s severe
> objections, I’ll go ahead and push this to up to master.
Emeric responded here:
http://marc.info/?l=haproxy&m=143643724320705&w=2
Not sure what you mean by pushing this to master...?
Lukas
Hey guys,
I haven’t gotten any feedback for this feature. Unless there’s severe
objections, I’ll go ahead and push this to up to master.
Thanks,
-Dave
On 7/7/15, 3:21 PM, "Dave Zhu (yanbzhu)" wrote:
>Hey guys,
>
>Sorry for the radio silence, other projects picked up and so I was unable
>to put
Hi Dave,
Could you re-indent your code. You've created a lot of unnecessary diffs in
your patch and there is too much interferences for a clean review.
i.e.
On 07/07/2015 09:21 PM, Dave Zhu (yanbzhu) wrote:
> - if (bind_conf->default_ctx) {
> - memprintf(err, "%sthis version of
Hey guys,
Sorry for the radio silence, other projects picked up and so I was unable
to put any time into this until now.
I¹ve gotten the feature to work against OpenSSL 1.0.2. I am able to do it
without peeking into any internal OpenSSL #defines and without using any
additional callbacks.
Howeve
> Thank you for pointing this out, I missed it in my brief look of the code.
> To me, this is reason enough to move to 1.0.2 (in addition to all the
> other reasons given by you and Nenad).
>
> I¹ll start prototyping the code using 1.0.2.
Agreed.
What I would also urge is to not use any openssl i
Hey,
>Yes, sorry, I didn't realize it earlier but that's not true for all
>OpenSSL versions. Starting with OpenSSL 1.0.0, tls1_process_ticket()
>will decline decrypting session tickets sent by the client if the
>session_secret_cb is in use:
>
>if (s->tls_session_secret_cb)
Hello,
Everything said here is based on my opinion, so just add "IMO" in front
of every sentence :)
On 6/25/2015 6:01 PM, Remi Gacogne wrote:
> Hi,
>
>> I was unaware that BoringSSL removed the callback, but in that case, could
>> we limit this feature to only OpenSSL? I¹m also not seeing how us
Hi,
> I was unaware that BoringSSL removed the callback, but in that case, could
> we limit this feature to only OpenSSL? I¹m also not seeing how using this
> callback prevents rfc5077, could you please elaborate.
Yes, sorry, I didn't realize it earlier but that's not true for all
OpenSSL version
On 6/25/15, 5:17 AM, "Remi Gacogne" wrote:
Hey Remy, thanks for your feedback!
>
>However, I have some concerns about the use of
>SSL_set_session_secret_cb() for this feature, because it was clearly not
>designed for this kind of manipulation. It has been removed from
>BoringSSL [1] and simply e
Hi all,
Dave, thank you for proposing this feature, I truly think that being
able to serve RSA or ECDSA certificates depending on what the client
supports would be an awesome addition to HAproxy.
However, I have some concerns about the use of
SSL_set_session_secret_cb() for this feature, because
On 6/24/15, 2:58 PM, "Willy Tarreau" wrote:
>What I'm understanding here is that instead of using SNI only as the key
>to pick a cert, we want the (SNI, algo) combination. Coudln't we have two
>certs per SNI entry ? One in RSA form, the other one in ECDSA, and only
>provide what is supported ? We
On Wed, Jun 24, 2015 at 03:06:32PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy,
>
> Lukas explained it pretty well, but I can expound on it some more.
>
> You can imagine a situation where HAProxy has 2 certificates of different
> key types; one ECDSA and one RSA. In the current codebase, if no
On Wed, Jun 24, 2015 at 04:26:58PM +0200, Lukas Tribus wrote:
> Currently we mostly use RSA certificates. ECC (ECDSA) are different
> certificates and
> until RSA certificates are fully removed from the industry, we will have to
> support both.
>
> The change, if I understand correctly, allows se
And a quick update on why supporting both (ECDSA / RSA) certificates :
first one is newer and only supported in latest browsers, but is really
interesting with heavy SSL load because it is much cheaper on CPU cost
server side (main work is done on client browser).
2015-06-24 18:53 GMT+02:00 Dave Z
I’ve coded up the functionality to check all of the intermediate
certificates to ensure that they match the private key of the crt file.
I’ve decided to toggle this functionality as a config option. Users can
either choose to disable this entire feature (default), match only the
private key/cert, o
No, I do not handle that case at the moment. This is the kind of feedback
I¹m looking for so thanks!
I will start modifying the code to try to accommodate this.
Any thoughts on the version of OpenSSL to try to code to?
-Dave
On 6/24/15, 11:54 AM, "Lukas Tribus" wrote:
>
>Does your code correc
> Hey Willy,
>
> Lukas explained it pretty well, but I can expound on it some more.
>
> You can imagine a situation where HAProxy has 2 certificates of different
> key types; one ECDSA and one RSA. In the current codebase, if no SNI is
> used, the certificate that is used will be whichever certific
Hey Willy,
Lukas explained it pretty well, but I can expound on it some more.
You can imagine a situation where HAProxy has 2 certificates of different
key types; one ECDSA and one RSA. In the current codebase, if no SNI is
used, the certificate that is used will be whichever certificate is the
d
Hi,
On Wed, Jun 24, Willy Tarreau wrote:
> On Tue, Jun 23, 2015 at 06:07:43PM +, Dave Zhu (yanbzhu) wrote:
> > Hello all,
> >
> > I have a proposed enhancement that I have coded up and would like your
> > comments.
> >
> > The idea behind this is that when HAProxy is used to terminate SSL,
>> Currently, I?ve coded it so that this only happens when the client does not
>> specify an SNI, but I?m looking for guidance on what you would consider to be
>> the best solution. This approach can certainly be taken to be compatible with
>> SNI.
>>
>> Is this something that you would be interest
Hello Dave,
On Tue, Jun 23, 2015 at 06:07:43PM +, Dave Zhu (yanbzhu) wrote:
> Hello all,
>
> I have a proposed enhancement that I have coded up and would like your
> comments.
>
> The idea behind this is that when HAProxy is used to terminate SSL, and is
> configured with multiple certifica
Hello,
Great ! I was actually speaking about it this morning at work ! Would love
to see this feature integrated (can it be backported to 1.5 too ?)
2015-06-23 20:07 GMT+02:00 Dave Zhu (yanbzhu) :
> Hello all,
>
> I have a proposed enhancement that I have coded up and would like your
> comment
100 matches
Mail list logo