www.formilux.org

[Aadilah | Creative Video]

Hi, I hope you are well. I represent an experienced video production and
marketing company that has produced over 800 episodes and 1000 Promotional
videos. Plus we can actually help promote your company to the world as we
have broadcast partners locally, internationally and online with stunning
Viewer ships.

Take our Face book page for example, with well over 1.56 Million fans it is
the biggest Australian site of its type.

We can create a professional video package for you and back it up with
actual platforms for exposure.

Are you interested to promote your services through advanced video
marketing technologies?

Reply to this email and I will personally get back to you, not one of my
staff.

Yours sincerely,

*Aadilah | Video Analyst*
Creative Video
OFFICE 1615, 30 FOVEAUX STREET, SURRY HILLS, SYDNEY, NSW AUSTRALIA

Re: Problems with haproxy 1.7.3 on FreeBSD 11.0-p8

[Pavlos Parissis]

On 17/03/2017 05:57 μμ, Aleksandar Lazic wrote:
> Willy.
> 
> Am 14-03-2017 22:17, schrieb Willy Tarreau:
>> Matthias,
>>
>> I could finally track the problem down to a 5-year old bug in the
>> connection handler. It already used to affect Unix sockets but it
>> requires so rare a set of options and even then its occurrence rate
>> is so low that probably nobody noticed it yet.
>>
>> I'm attaching the patch to be applied on top of 1.7.3 which fixes it,
>> it will be merged into next version.
>>
>> Dmitry, you may prefer to take this one than to revert the previous
>> one from your ports, especially considering that a few connect()
>> immediately succeed over the loopback on FreeBSD and that it was
>> absolutely needed to trigger the bug (as well as the previously fixed
>> one, which had less impact).
>>
>> Or you may prefer to wait for 1.7.4. It's not planned yet given that
>> there are other fixes in the wild waiting for some feedback though.
>>
>> Thanks guys for the detailed feedback, it's now time to turn the page
>> and switch to less difficult ones!
> 
> I love your commit massages ;-).
> 

+1

> They are very detailed and sometimes bigger the the code change.
> 

Indeed. All commits, in any project, should be like this.

I personally follow the following rules:

1. short commit should be written, so that can be placed in the following 
sentence:
If you apply this commit it will 

2. Long commit message should clearly describe the problem, why it is a problem
and how the commit fixes the problem.

Having said, I have colleagues that not only follow the above rules but complain
to me about my very lengthy commit messages. I usually ignore them and redirect
their *rant* to /dev/null.

Cheers,
Pavlos




signature.asc
Description: OpenPGP digital signature

Re: Problems with haproxy 1.7.3 on FreeBSD 11.0-p8

[Willy Tarreau]

Hi Aleks,

On Fri, Mar 17, 2017 at 05:57:02PM +0100, Aleksandar Lazic wrote:
> I love your commit massages ;-).
> 
> They are very detailed and sometimes bigger the the code change.

That's expected, especially on a bug. The code is the result of a
long analysis. If this analysis is lost, next time we have to dig
through the same issue or have to decide wether to roll it back,
we don't know. The commit message is here to keep a trace of the
analysis work. That's why I *always* complain when people don't
provide detailed commit messages to justify their changes.

Cheers,
Willy

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Le 16 mars 2017 à 17:49, Emmanuel Hocdet  a écrit :Hi Emeric,Le 16 mars 2017 à 14:44, Emeric Brun  a écrit :I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.So for me the patch could modify some behavior for openssl versions < 1.1I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation.At worst, this can change something in openssl 0.9.x but it's for haproxy 1.8dev… It seem that use SSL_CTX_set_options is a good compatibly choice.The only thing i see is that no-tlsxx can generate a not recommented configuration (1.0.2)."The list of protocols available can be further limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating "holes" in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ configuration is equivalent to use SSL_CTX_set_options correctly.There is another point which worries me:In the proposed patch, statement 'force-' will disable all known protocol version except that one.But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.I agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be a better way to no care about new version.I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy directive (patch is ssl version agnostic).With this patches, all tls versions are supported and it’s easy to add new tls version internally.min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be more clear that with no-tlsxx and without « holes ».Add SSL_CTX_set_min/max_proto_version could be a option but i does not see the necessity.Manu

0001-MEDIUM-ssl-rework-of-ssl_method-calculation-to-match.patch
Description: Binary data


0002-MEDIUM-ssl-add-TLSv1.3-directives-and-min-method-max.patch
Description: Binary data

rsyslog -> tcp -> ssl -> SNI -> ssl -> rsyslog

[Aleksandar Lazic]

Hi.

The subject looks strange so let me the explain the setup a little bit.

I have a old rsyslog without ssl module.
I need to send syslog messages via tcp to a remote syslog server.

Between the local server and the remote server is a haproxy which I can 
only use as https-sni-forwarder.


https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html#secured-routes
-> Passthrough mode

I was able to run my docker image on the old rsyslog server.


docker run -it --rm --name rsylog-forwarder \
  -e SERVICE_DEST=logcollect.${DOMAIN} -e TZ=Europe/Vienna \
  -e SERVICE_NAME=rsylog-forwarder -e SERVICE_DEST_PORT=13443 \
  -e SYSLOG_ADDRESS=127.0.0.1 -e SERVICE_TCP_PORT=13443 \
  -e STATS_PORT=13444 -e 
CONFIG_FILE=/mnt/config/haproxy-sslforwarder.conf \

  -e DEBUG=true -v /etc/rsylog-forwarder/conf:/mnt/config \
  -v /etc/rsylog-forwarder/ssl:/mnt/certs \
  --expose 13443 --expose 13444 \
  --health-cmd 'curl -sS http://127.0.0.1:${STATS_PORT}' \
  --health-interval 5s --health-timeout 3s --entrypoint /bin/bash \
  -p 13443:13443 me2digital/haproxy17

in the container: bash -x container-entrypoint.sh


When I now call

logger --tcp --server 127.0.0.1 --port 13443 --tag aushape test aleks

Then I can see that the logger connects to the local haproxy but the 
haproxy does note connect to the 'logcollect.${DOMAIN}'


But when I call

curl -vk https://logcollect.${DOMAIN}/

I reach the haproxy inside via the openshift router.
So finally the setup works when I'am able to configure haproxy in that 
way that he acts like curl ;-)


Do you think this is possible?

Haproxy version 1.7.3
=> https://gitlab.com/aleks001/haproxy17-centos

Config 'local ssl forwarder tcp -> https'
=> https://gitlab.com/snippets/1654829

Config 'remote forwarder https -> tcp'
=> https://gitlab.com/snippets/1654828

Thanks for any feedback.

Cheers
aleks

Re: Problems with haproxy 1.7.3 on FreeBSD 11.0-p8

[Aleksandar Lazic]

Willy.

Am 14-03-2017 22:17, schrieb Willy Tarreau:

Matthias,

I could finally track the problem down to a 5-year old bug in the
connection handler. It already used to affect Unix sockets but it
requires so rare a set of options and even then its occurrence rate
is so low that probably nobody noticed it yet.

I'm attaching the patch to be applied on top of 1.7.3 which fixes it,
it will be merged into next version.

Dmitry, you may prefer to take this one than to revert the previous
one from your ports, especially considering that a few connect()
immediately succeed over the loopback on FreeBSD and that it was
absolutely needed to trigger the bug (as well as the previously fixed
one, which had less impact).

Or you may prefer to wait for 1.7.4. It's not planned yet given that
there are other fixes in the wild waiting for some feedback though.

Thanks guys for the detailed feedback, it's now time to turn the page
and switch to less difficult ones!


I love your commit massages ;-).

They are very detailed and sometimes bigger the the code change.

Cheers
Aleks


Willy

Re: Problems with haproxy 1.7.3 on FreeBSD 11.0-p8

[Matthias Fechner]

Dear Willy and Dmitry,

Am 14.03.17 um 22:17 schrieb Willy Tarreau:

Or you may prefer to wait for 1.7.4. It's not planned yet given that
there are other fixes in the wild waiting for some feedback though.

Thanks guys for the detailed feedback, it's now time to turn the page
and switch to less difficult ones!


I rolled now the 1.7.3 (version with the new patch) to the test 
environment and it seems to work reliably.


But the other message you wrote seems to point to another problem.

If you need any help for testing, please let me know.

Gruß,
Matthias

--
"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the universe trying to 
produce bigger and better idiots. So far, the universe is winning." -- 
Rich Cook

WebSocket + compression + timeout tunnel broken in v1.7?

[Kristjan Koppel]

Hi!



I upgraded a HAProxy instance from v1.6.10 to v1.7.3 with no changes to 
configuration and I noticed that now clients connecting to a WebSocket backend 
are getting disconnected after being idle for "timeout client" time rather than 
the much longer "timeout tunnel" time. As I understand it, "timeout tunnel" is 
supposed to override the "timeout client" setting for WebSocket sessions and 
this worked fine with v1.6 and earlier.



Also, this HAProxy instance has compression enabled in the defaults section. If 
I remove the compression settings from there (or if I move them to other 
backends only), then "timeout tunnel" starts to work again. So, I guess this is 
a bug in HAProxy v1.7?



I managed to reproduce this with the official HAProxy Docker images, a minimal 
haproxy.cfg and wscat (from the Debian package node-ws) as follows:



haproxy.cfg:


global

stats socket /run/haproxy.sock mode 660 level admin

stats timeout 30s

daemon



defaults

modehttp

timeout connect 5s

timeout client  50s

timeout server  60s

timeout tunnel  15m



compression algo gzip

compression type text/html



listen ws_test

bind :8000

server wscat 172.17.0.1:8001





I started one wscat instance in listening mode for the backend:

$ wscat -l 8001



With HAProxy v1.6.11 running the above config I see the following:

$ date; wscat -c ws://172.17.0.2:8000; date

Fri Mar 17 12:10:59 EET 2017

connected (press CTRL+C to quit)

 foo

 bar

disconnected

Fri Mar 17 12:26:03 EET 2017


State of the session about 30 seconds after starting the above command:
$ echo "show sess" | socat /run/haproxy.sock stdio

0x12253b0: proto=tcpv4 src=172.17.0.1:52046 fe=ws_test be=ws_test srv=wscat 
ts=08 age=31s calls=4 rq[f=8848202h,i=0,an=00h,rx=14m32s,wx=,ax=] 
rp[f=88048202h,i=0,an=00h,rx=14m32s,wx=,ax=] s0=[7,8h,fd=1,ex=] 
s1=[7,118h,fd=2,ex=] exp=14m29s




With HAProxy v1.7.3 running the same config I see the following:

$ date; wscat -c ws://172.17.0.3:8000; date

Fri Mar 17 12:29:39 EET 2017

connected (press CTRL+C to quit)

 foo

 bar

disconnected

Fri Mar 17 12:30:33 EET 2017



Obviously it takes me a bit of time to send the 2 strings manually, so total 
time is a bit more than the "timeout client" value here.



State of the session about 30 seconds after starting the above command:

$ echo "show sess" | socat /run/haproxy.sock stdio

0x22a4f10: proto=tcpv4 src=172.17.0.1:55996 fe=ws_test be=ws_test srv=wscat 
ts=04 age=33s calls=6 rq[f=8848000h,i=0,an=00h,rx=20s,wx=,ax=] 
rp[f=88048000h,i=0,an=00h,rx=30s,wx=,ax=] s0=[7,8h,fd=1,ex=] 
s1=[7,118h,fd=2,ex=] exp=20s





If I remove the compression lines from the config and try again with HAProxy 
v1.7.3, then it's fine again:

$ date; wscat -c ws://172.17.0.3:8000; date

Fri Mar 17 12:35:22 EET 2017

connected (press CTRL+C to quit)

 foo

 bar

disconnected

Fri Mar 17 12:50:26 EET 2017



State of the session about 30 seconds after starting the above command:

$ echo "show sess" | socat /run/haproxy.sock stdio

0x1e64500: proto=tcpv4 src=172.17.0.1:56038 fe=ws_test be=ws_test srv=wscat 
ts=04 age=31s calls=5 rq[f=8848000h,i=0,an=00h,rx=14m33s,wx=,ax=] 
rp[f=88048000h,i=0,an=00h,rx=14m33s,wx=,ax=] s0=[7,8h,fd=1,ex=] 
s1=[7,118h,fd=2,ex=] exp=14m33s



I'll be happy to provide any additional information if needed.





-- 

Kristjan

Re: Problems with haproxy 1.7.3 on FreeBSD 11.0-p8

[Willy Tarreau]

Hi Dmitry,

On Wed, Mar 15, 2017 at 12:45:54AM +0300, Dmitry Sivachenko wrote:
> I committed your patch to FreeBSD ports.

I was just reported an undesired side effect of this patch with smtp
in clear without proxy-proto :-(

The problem is that we're using the CONNECTED flag to indicate whether
we've just detected the transition from pending handshake to connected
or not. And the data layer also needs to see the transition so we can't
set it too early.

Thus in order to fix Matthias' issue I'm tempted by extending the
CONN_STATE flag to cover all handshakes, but I'm scared to break
complex health checks by calling them multiple times when multiple
layers are stacked (eg: ssl + send_proxy).

The root cause of the problem is the fact that we don't cover the
handshakes completion when deciding to wake the data layer up, and
that these ones are supposed to (sometimes) complete a connection
establishment (eg: Matthias' case where the successful connect()
didn't leave room for another event to report this).

I *think* we can use as a universal event the absence of any
handshake, any pending L4/L6 pending connection and the absence
of the CO_FL_CONNECTED flag, indicating we're just finishing a
connection validation. I need to verify if it would work both
for checks and regular connections, and on both sides, in a wide
variety of combinations. I also don't feel much confident by the
fact that the stream interface layer validates the connection
establishment without checking for pending handshakes, so such
a change requires extreme care :-/

I'm now working on this (I didn't expect to do this today) but I
already feel like I'm pulling one thread and that the whole ball
is coming with it. Let's hope that it will end up with all these
design bugs being smashed :-/

In your case, if you get bad reports it might be better to go back
to the previous package with the temporary revert. But I hope to
have good news today so that you don't have to emit two package
updates.

Regards,
Willy

Re: Considering HAProxy to Bump TLS 1.1 Traffic to TLS 1.2

[Marco Corte]

Hello, Ryan!

I also propose a different approach... just in case.

I had the same problem with some further constraints.
The Java client runs on Windows and an haproxy instance running on 
another server was very difficult to setup complying to all the security 
policies.


In this case it was much easier to setup a stunnel instance on the 
Windows server instead of fighting with the security auditor ;-)


.marcoc