OpenSSL engine and async support

This patch set adds the basic support for OpenSSL crypto engine and async mode. Changes since V2: - support keyword "algo" - ensure SSL engines are initialized before loading certs. - limit one async fd per SSL connection - better integrate with event cache Changes since V1: - add multiple

[PATCH V3 1/2] ssl: add basic support for OpenSSL crypto engine

This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used. --- doc/configuration.txt | 16 ++

[PATCH V3 2/2] RFC: add openssl async support

ssl_async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC mode set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to

Re: [PATCH] MEDIUM: ssl: Add TLS-PSK client and server side support

On Fri, Feb 03, 2017 at 02:19:29AM +0100, Nenad Merdanovic wrote: > +psk-file > + Enables use of PSK cipher suites with PSKs stored in the specified file. > + The entries should be in form "identity:key", one per line. > + Rather than new file handling routine, could you instead hook this into

Re: Building Haproxy 1.7.2 against LibreSSL 2.5.1

I've made a patch to build Haproxy against LibreSSL 2.5.1. This is based on OpenBSD patch, but OpenBSD still has 1.6.11, so I've made some additions. On 17-02-03 14:13:09, Piotr Kubaj wrote: > I've also tried to build 1.8-dev0-20170131, which fails with the same errors. > > On 17-02-02

[Feature Request] Expose UDP socket from luasocket

Any chance of exposing the UDP functionality[1] from lua socket? [1] http://w3.impa.br/~diego/software/luasocket/udp.html

converters in http-request replace-header

I am seeing what I believe is a bug when converters are used with http-request replace-header. I have the following configuration: global maxconn 5 defaults mode http timeout connect 30s timeout client 1m timeout server 1m listen test bind :80

Re: Gzip compression and transfer: chunked

Le 03/02/2017 à 14:36, Kristjan Koppel a écrit : Hi! I seem to have run into the same (or at least similar) problem as reported by Vladimir Mihailenco a little while ago. I'm running HAProxy v1.7.2 and my backend server is etcd v2.3.7. The client application is using HTTP/1.0 and I have

Re: Gzip compression and transfer: chunked

I too am seeing something similar with HAProxy 1.7.2. My test configuration is: global maxconn 5 defaults mode http option http-server-close compression algo gzip timeout connect 30s timeout client 1m timeout server 1m listen fe bind :80 server primary

Re: Gzip compression and transfer: chunked

Hi! I seem to have run into the same (or at least similar) problem as reported by Vladimir Mihailenco a little while ago. I'm running HAProxy v1.7.2 and my backend server is etcd v2.3.7. The client application is using HTTP/1.0 and I have compression enabled in HAProxy. With this

Re: haproxy cascade SOLVED

> >>> Hi, >>> >>> On Fri, Feb 03, Antonio Trujillo Carmona wrote: All this go fine, but balanced A don't know state of virtual machine but state of haproxy in server, due this if we stop VM1 and we see state in balanced A we see VM is OK, that is because Balanced A see then state

Re: Building Haproxy 1.7.2 against LibreSSL 2.5.1

I've also tried to build 1.8-dev0-20170131, which fails with the same errors. On 17-02-02 09:38:19, Piotr Kubaj wrote: > Hello, > > I'm trying to build Haproxy 1.7.2 on FreeBSD 11.0 against LibreSSL 2.5.1. I'm > building from FreeBSD ports with: > DEFAULT_VERSIONS= ssl=libressl-devel > in

Debug Log: Response headers logged before rewriting

Hi there! I currently trying to figure out a problem with request and response header rewriting. To make things easier I run haproxy in debug mode, so I get the client/server conversation all dumped to my terminal. I am wondering, however, if I am missing something, because apparently the

Re: Start From Zero concept

This is exactly like Zerg http://erlangonxen.org/zerg the requirements are that haproxy: - triggers launching a new backend immediately on accepting the tcp handshake or ssl initiation - holds the frontend tcp connection open until the new backend is spun up - triggers closing the backend on

Re: haproxy cascade

Ok I miss understood you, option httpchk GET /healthcheck and http-check expect status 200 are in different row, but it don't work neither. >> Hi, >> >> On Fri, Feb 03, Antonio Trujillo Carmona wrote: >>> All this go fine, but balanced A don't know state of virtual machine but >>> state of

RE:haproxy cascade

> Hi, > > On Fri, Feb 03, Antonio Trujillo Carmona wrote: >> All this go fine, but balanced A don't know state of virtual machine but >> state of haproxy in server, due this if we stop VM1 and we see state in >> balanced A we see VM is OK, that is because Balanced A see then state of >> haproxy

Re: haproxy cascade

Hi, On Fri, Feb 03, Antonio Trujillo Carmona wrote: > All this go fine, but balanced A don't know state of virtual machine but > state of haproxy in server, due this if we stop VM1 and we see state in > balanced A we see VM is OK, that is because Balanced A see then state of > haproxy in server 1

haproxy cascade

Hello. first thank for your work, and sorry for my bad English. In my work (an hospital) we are trying to pass all the connection to SSL. We have: | [VM 1]| |[balanced A (haproxy + keepalived)]| |server 1 [VM 3]| |