Hi guys,
On Tue, Sep 24, 2013 at 09:07:23PM +0200, Lukas Tribus wrote:
> Hi everyone,
>
>
> > An important reason to release the SSL feature set as is could be for
> > the potential to release timely security fixes when vulnerabilities or
> > exploits are discovered.
>
> Security problems are fixed in both 1.5 and 1.4 branches at the same
> time with new releases, see 1.4.24/1.5-dev19 and 1.4.23/1.5-dev18.
>
> Willy is very well aware that 1.5 is widely used in production.
Yes, clearly. we're using it in the ALOHA and at a number of customers
under specific support. In practice, it happens that 1.5 is in prod at
larger sites than 1.4, not because it's faster, but because it provides
the track counters that larger sites need to counter abuses and DoS
attacks.
> > Unfortunately we don't have the resources to maintain a branch to
> > which we could backport relevant fixes, not to mention the overhead of
> > managing any security related fixes.
>
> Willy is very transparent with security issues and its fixes are usually
> just a small patches, so the "backport" is really only a question of
> downloading a single patch and applying it.
Well, I'd say that there are two ways to deal with backports :
- use 1.4 with some feature backports (eg: proxy protocol maintained
by Cyril)
- use 1.5 with backport for bug fixes (including security fixes).
The first solution probably is the easiest one if no 1.5-specific features
are needed. Simply apply a few patches on top of the latest 1.4 snapshot
and/or release and that's all.
The second one needs to invest time. There's no alternative. We do this for
our ALOHA product and when we have to fix some issues, we only backport
fixes to the version we have chosen as a base for the product branch. And
I guess that our colleagues at Loadbalancer.org do the same, simply because
it is the only way to use a rolling version and provide responsible updates
at the same time to end users.
> Also, in contrast to other projects, Willy and the mailing list do
> provide full support for 1.5 and appreciate bug reports for it. So if
> you have troubles backporting a security relevant fix, I think the mailing
> list will help without hesitation.
Yes, for sure!
> I do completely understand your worries about using a development version
> in production. Like I said, if this is a showstopper for deploying HAproxy,
> then you need commercial support:
With no doubt. Tu put it clear, when it's *your* business, you probably
want to save a few k$ and do the job yourself. But when you have a boss
with a budget or simply customers paying for the service, you'll probably
prefer to pay some company to save your ass. That's why we're not afraid
of working on opensource and selling integrated products at the same time,
there's place for everything and there's demand for everything.
> >> If you don't have the time and need those bleeding edge features
> >> today, then you should probably stick to a commercial solution,
> >> like those from exceliance.fr or loadbalancer.org.
> >
> > I'm not sure if either of these offer websocket+SSL support, but
> > certainly worth investigating.
>
> I should've made it clear: Exceliance products are based on HAProxy *1.5-dev*
> and Willy is actually an employee (or even a founder).
>
> So if your configuration does work with haproxy 1.5, Exceliance will get the
> job done (and the fees will probably fund further development of HAProxy in
> one way or another).
Confirmed :-)
> Given the code contributions of loadbalancer.org I highly suspect they have
> some HAproxy based products as well.
Yes, and the best is that we almost never compete and even work together
from time to time in the back yard to get some bugs fixed !
> > With the knowledge that server-side keep-alives aren't currently
> > supported together with SSL we could plan our production deployment to
> > take this into account until a future release does support the
> > combination. Documentation could very well reflect these limitations
> > and serve to manage users expectations.
>
> A single OSS product will never cover all the aspects and requirements all
> the different users have, but it doesn't need to, imho.
BTW, the lack of server-side keep-alive is clearly documented in the
configuration manual.
> Thats why we
> (in the IT industry) have commercial products, paid 24/7 support, SLAs and
> features requests with business cases behind it, even if the actual source
> code is open.
>
> Have CentOs, but want to sleep better? Get RHEL with commercial support.
That's exactly the same.
Now let me give some more info about server-side keep-alive. There are
two reasons why I want this to be complete before releasing 1.5. Usually,
keep-alive to application servers is useless or even counter-productive
if connections cannot be multiplexed (which is the default case when you
don't have the *guarantee* that the application supports this). However,
there is a situation where you need server-side keep-alive : NTLM
authentication. NTLM is broken in that it authenticates the *connection*
instead of the *request*, which is absolutely incompatible with HTTP and
is a major security hole. But it's been done that way and for some users
we have to support this. Right now the only way to support it is to work
in tunnel mode, limiting the ability to log requests or to direct them to
the appropriate server farm. In practice it works because the use cases
are simple, but that's ugly and error-prone. The second case is with
static servers or caches like varnish which are extremely fast and support
large amounts of concurrent connections. On them it's a waste to close and
re-establish connections, especially for small objects. Again, working in
tunnel mode is generally fine but prevents the use of content switching to
select a different farm.
I've identified some preliminary changes that are required before KA is
possible (related to the way stats are implemented). Some other issues
related to hash-based algorithms have surfaced (eg: we'll have to let the
user chose if the hash is strict or relaxed). But I have an overall vision
of how it can work in a basic way to support the two use cases above.
Later we'll improve it to support multiplexing, but that's not required
for 1.5.
Recent significant changes in my job have substantially delayed all this
work (more on that later), but I'm confident we're getting closer to a
release.
Regards,
Willy
