[PATCHv3] openssl-compat: Fix getm_ defines

[Rosen Penev]

LIBRESSL_VERSION_NUMBER evaluates to 0 under OpenSSL, making the condition
always true. Check for the define before checking it.

Signed-off-by: Rosen Penev 
---
 v3: Added BoringSSL support
 v2: Switched to HA_OPENSSL_VERSION_NUMBER as it's cleaner.
 include/common/openssl-compat.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/common/openssl-compat.h b/include/common/openssl-compat.h
index 25102fbe3..31971bd9e 100644
--- a/include/common/openssl-compat.h
+++ b/include/common/openssl-compat.h
@@ -278,7 +278,8 @@ static inline void EVP_PKEY_up_ref(EVP_PKEY *pkey)
 #define TLSEXT_signature_ecdsa  3
 #endif
 
-#if (OPENSSL_VERSION_NUMBER < 0x1010L) || (LIBRESSL_VERSION_NUMBER < 
0x2070L)
+#if ((HA_OPENSSL_VERSION_NUMBER < 0x101fL) && (LIBRESSL_VERSION_NUMBER < 
0x207fL)) ||\
+   defined(OPENSSL_IS_BORINGSSL)
 #define X509_getm_notBefore X509_get_notBefore
 #define X509_getm_notAfter  X509_get_notAfter
 #endif
-- 
2.23.0

Re: [PATCH] MINOR: ssl: add "ca-root-file" directive

[Emmanuel Hocdet]

With this proposition, ca-root-file should be rename to something like 
ca-end-file.
Refer to https://github.com/haproxy/haproxy/issues/404 
 discussion.

> Le 19 déc. 2019 à 13:10, Emmanuel Hocdet  a écrit :
> 
> 
> Hi,
> 
> The purpose of this patch is to fix #404 and keep compatibility with actual
> "ca-file » directive for bind line.
> 
> ++
> Manu
> 
> <0001-MINOR-ssl-add-ca-root-file-directive.patch>
> 

customize format of haproxy X-ForwardedFor ssl_c_s_dn during SSL termination

[Chris Software]

I am running haproxy in an Alpine Docker container. It is doing SSL
termination for https and injecting the client DN into the X-ForwardedFor
HTTP Header. But the format it uses for the client DN is not one that my
application supports.

Can I change the format somehow, perhaps using openssl.cnf? People
apparently change encryption algorithm settings that way. Can I change my
DN format also?

This is the format that I need my certificate DN to look like in the
X-ForwardedFor header. It is rather LDAP-ey.

CN=Jane Smith,OU=org1,OU=org2,O=myorg,C=AU

But haproxy is injecting a rather ASN.1 looking format

/C=AU/O=myorg/OU=org2/OU=org1/CN=Jane Smith

These are the verisons of the software. They can be changed, as I am
compiling haproxy from source. I can also set any flags at compilation time:

   1. Haproxy 2.0
   2. Alpine 3.10
   3. openssl 1.1.1

Here are what I think are the relevant parts of the haproxy.cfg file .

frontend fe
mode http
bind *:443 ssl no-sslv3 no-tls10 no-tlsv11 crt /certs/mycert
ca-file /certs/myca
option forwardfor
http-request set-header X-ForwardedFor %{+Q+E}[ssl_c_s_dn]
default_backend be

backend be
   balance source
   mode http
   server server1 IP:PORT ca-file /certs/myca crt /certs/mycert ssl verify none

Is there something I can do to change the format? I have tried using the
documented structure like this: %{+Q+E}[ssl_c_s_dn(CN)] but the format of
my certificate DNs is very disorganized. There is no way to predict how
many OU, C, O, etc there might be, and sometimes they are missing. So I
don't think that is a viable solution.

I have also looked at how this question: haproxy tls hash algorithm

customizes
haproxy behavior with openssl settings. Can I do that to get the DN into a
different format? If so, how? I am not sure what steps to follow. Do I need
to modify openssl.cnf at compile time, or have it changed at runtime on the
server? What sections and values?

Thank you!

[PATCH] MINOR: ssl: add "ca-root-file" directive

[Emmanuel Hocdet]

Hi,

The purpose of this patch is to fix #404 and keep compatibility with actual
"ca-file » directive for bind line.

++
Manu



0001-MINOR-ssl-add-ca-root-file-directive.patch
Description: Binary data

Re: How to "unit" test HAProxy configurations (and HTTP servers in general)

[Ciprian Dorin Craciun]

On Thu, Dec 19, 2019 at 7:08 AM Илья Шипицин  wrote:
>> Really I would have expected to find a lightweight and generic Python
>> or Ruby "framework" that allows one to write such tests in a more
>> "programmatic" manner...  :(
>
> python mechanize ?


Looking at the documentation, https://mechanize.readthedocs.io/, it
seems targeted towards HTML testing and automation, say something more
similar to Selenium.

But the direction is quite good, i.e. it includes programatic
definition, however I'm serching something targeting mainly the
HTTP-layer, and as added-value if it allows me to write "application"
tests the better.  :)


Aside from `mechanize`, there seems to be two categories of tools, at
opposite ends, without any overlapping:
* we have the web-application testers, like Postman, `mechanize` (from
what I've seen), a few other (especially NodeJS-based)
implementations, that focus exclusively on the application layer;
(i.e. HTML, JSON, forms, etc.)
* we have the low-level HTTP-layer load generating tools like `wrk` or
`ab`, that have almost no capability of checking the "application"
layer, and most of the time neither the HTTP layer;
* and we have `vtest` / `varnishtest` (and perhaps a few others that I
haven't found yet) that also focus on the HTTP-layer, but mainly only
target the proxy / cache aspect of it, and lack basic functionality
for any application testing;

I'm searching for something "in-between".  :)

Thanks,
Ciprian.

Re: [2.1.1] http-request replace-uri does not work

[Willy Tarreau]

On Tue, Dec 17, 2019 at 07:06:37AM +0100, Willy Tarreau wrote:
> Actually a slightly cleaner one that should even be backportable to 2.0.
(...)
replace-path now merged and backported to 2.1.

Willy

Re: How to "unit" test HAProxy configurations (and HTTP servers in general)

[Ciprian Dorin Craciun]

On Thu, Dec 19, 2019 at 9:10 AM Jarno Huuskonen  wrote:
> > So my question to the HAProxy community is if anyone knows / uses a
> > generic HTTP unit testing framework.
>
> Have you looked into varnishtest(vtest) ? There're examples in haproxy source
> reg-tests directory.


Interesting;  for reference I'll put the relevant links bellow:

  https://github.com/vtest/VTest -- the actual tool used by HAProxy
  https://github.com/haproxy/haproxy/tree/master/reg-tests
  https://varnish-cache.org/docs/trunk/reference/varnishtest.html
  https://varnish-cache.org/docs/trunk/reference/vtc.html#haproxy

I'll have a more closer look, however at a first glance the following
sticks out to me:
* (as a plus)  it seems to be quite competent and allows many
use-cases;  (even checking very low-level details such as TCP
window-size;)
* (as a minus)  the syntax is quite awkward;  therefore it will be
very hard for most to write checks;
* (as a minus)  it can't be extended into more "application-side"
testing;  (i.e. what Postman does best;)
* (as a minus)  I think it's targeted more at testing small,
individual, features, as for example I don't think it's able to
generate the test cases (including URLs, headers, etc.)
programatically, for example taking them from a file, etc.;

Thanks for the pointer, I'll take a closer look and perhaps I'm
mistaken about many of the above,
Ciprian.

Re: [RFC PATCH] HTTPS connection reuse with SNI

[Julien Pivotto]

On 18 Dec 16:46, Joshua Knox wrote:
> A github issue was filed at https://github.com/haproxy/haproxy/issues/371
> 
> The CONTRIBUTING guidelines requested discussion on the list, I believe the
> included diff would address that issue and arguably be less surprising
> behavior.
> 
> The comment from ehocdet on the issue indicated that connection reuse could
> be reused if SNI was incorporated into connection selection criteria.  I
> think that that larger change would make sense for reuse in "http-reuse
> safe" mode.
> 
> There are currently a number of explicit checks for "http-reuse never" that
> set the private connection flag (CO_FL_PRIVATE), I think that failing to
> set it in this case is the logical counterpart.
> 
> Thanks in advance,
> Josh

I would actually like the idea to remove the criteria to not reuse SNI
connection, even in safe mode. After all there is not big difference
once the connection is established and we can not change the value of
sni() between requests anyway.

-- 
 (o-Julien Pivotto
 //\Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu


signature.asc
Description: PGP signature

Re: [RFC PATCH] MINOR: debug: allow debug converter in default build

[Willy Tarreau]

Hi,

On Tue, Dec 17, 2019 at 11:05:27AM +0100, Willy Tarreau wrote:
> OK, so here's what I came up with. Should I merge it or does anyone have
> any comment about it ?

So barring any objection I've now merged it and backported it to 2.1
for now.

Willy