Re: Denying client certificates

[Lukas Tribus]

Hello,


Am 06.10.2017 um 15:33 schrieb Marco Corte:
>
> Is there a way to deny the access to some certificates without using a 
> certificate revocation list?
> I am trying with ACLs like
>
>   acl revoked_cert ssl_c_serial,hex 0x25
> or
>   acl revoked_cert ssl_c_sha1,hex 0xFC481501DB98290C5E9B22530D2CA73EB36E76C5
>

I think this should be:
acl revoked_cert ssl_c_sha1 -m bin FC481501DB98290C5E9B22530D2CA73EB36E76C5

According to the configuration manual:
http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#7.1.5


Note that you do NOT prepend "0x" to the hex value and use "-m bin" for the 
comparison:


cheers,
lukas

lua / rewrite arbitrary portions of http request (headers + content)

[Mark Staudinger]

Hi Folks,

I'm testing a use case that I've handled previously with header rewrites,  
but I would like to replace arbitrary strings in both the request header  
and request body.


I've enabled request buffering and also http-server-close to simplify  
things and avoid streaming requests as per some other examples that I've  
seen.


SAMPLE LUA CODE:

function mod_body(txn)
  local reqbody = txn.req:get()
  reqbody = string.gsub( reqbody, 'fixed-string-1', 'fixed-string-2' )
  txn.req:set( reqbody )
  --txn.req:send( ??? reqbody )
end
core.register_action( "do_something", { "http-req" }, mod_body )

-

In testing I would call this from haproxy in a backend like so:

  http-request lua.do_something if METH_POST

I've also tried in the frontend.

I'm not certain this use case is supported so I haven't done extensive  
testing, but if I simply call "txn.req:set( reqbody )" then haproxy exits  
on signal 11.


As you can see from the commented line I was also experimenting with  
calling txn.req:send but it requires another argument, and it's not clear  
to me what the argument should be in this context.


So it would seem that one of these things is occurring:

1) I'm using the wrong channel call to end this function
2) This could work, but I would need to read the http request buffer one  
line at a time, process, and then call either txn.req:set() or  
txn.req:send() when completed

3) This isn't expected to work and I should pursue other methods

Any advice, general or specific?

Many thanks,
-=Mark

Re: Haproxy refuses new connections when doing a reload followed by a restart

[Moemen MHEDHBI]

Hi Lukas,


On 04/10/2017 22:01, Lukas Tribus wrote:
> I guess the problem is that when a reload happens before a restart and 
> pre-reload
> systemd-wrapper process is still alive, systemd gets confused by that old 
> process
> and therefor, refrains from starting up the new instance.
>
> Or systemd doesn't get confused, sends SIGTERM to the old systemd-wrapper
> process as well, but the wrapper doesn't handle SIGTERM after a SIGUSR1
> (a hard stop WHILE we are already gracefully stopping).
>
>
> Should the systemd-wrapper exit after distributing the graceful stop message 
> to
> processes? I don't think so, it sounds horribly.
>
> Should the systemd-wrapper expect a SIGTERM after a SIGUSR1 and sends the
> TERM/INT to its childs? I think so, but I'm not 100% sure. Is that even the 
> issue?
>
>
>
> We did get rid of the systemd-wrapper in haproxy 1.8-dev, and replaced it 
> with a
> master->worker solution, so I'd say there is a chance that this doesn't 
> affect 1.8.
>

A. It appears to me that it is not the wrapper that receives the SIGUSR1
but the haproxy process.

B. Here is how I technically explain the "bug" (to be confirmed by the
Devs) reported by Niels:
 - During the reload:
  1. A SIGUSR2 is sent to the systemd-wrapper
  2. The wrapper sends SIGUSR1 to haproxy processes listed in the pid file.
  3. A new haproxy process is listening for incoming connections and the
pid file now contains only the pid of the new process.
- Then when issuing a restart/stop:
 1. A SIGTERM is sent to the systemd-wrapper
 2. The wrapper sends SIGTERM to haproxy processes listed in the pid file.
 3. Only the new haproxy process is stopped the other one is still there
since it did not receive the SIGTERM
- This why systemd is getting confused and after the timeout systemd
gets done with this by sending a SIGTERM to all child process
(killmode=mixed policy)

C. I was able to verify this by doing the following:
 1. After the reload I manually add the old process pid to the pidfile
 2. Then When I hit restart, all process are stopped correctly.

So the question is ( @William ): when doing a soft stop should we
preserve old process pid in the pidfile until the process terminates ?

-- 
Moemen MHEDHBI

Re: [PATCHES] 51d: fix warning when building with 51Degrees release version 3.2.12.12

[Willy TARREAU]

On Fri, Oct 06, 2017 at 11:03:27AM +, Ben Shillito wrote:
> Hi Willy,
> 
> Don't worry, it's an easy mistake.
> 
> Yeah, you're absolutely right, my mistake.

No worries, you're welcome.

> I assumed that both the URLs were "github.com/51degrees", however as the 
> first one is "git.51degrees.com" which does indeed contain the deprecated 
> Trie source, you can carry on using 3.2.10 on this URL.

Ah OK, got it!

> I have attached a patch on top of Dragan's which updates the branch name for 
> 3.2.12 and adds instructions for obtaining a free Hash Trie data file.

Perfect, I've applied it now. And I also agree with you that it's
important to encourage users to upgrade whenever they don't see any
showstopper.

Thanks!
Willy

Denying client certificates

[Marco Corte]

Hello, list.

In HAproxy 1.7.9 a frontend authenticates clients via SSL certificate
  ...
  bind 1.1.1.1: ssl crt /etc/ssl/private/XXX.pem force-tlsv12 
ca-file /etc/ssl/YYY.pem verify required

  ...

Is there a way to deny the access to some certificates without using a 
certificate revocation list?

I am trying with ACLs like

  acl revoked_cert ssl_c_serial,hex 0x25
or
  acl revoked_cert ssl_c_sha1,hex 
0xFC481501DB98290C5E9B22530D2CA73EB36E76C5


and then

  tcp-request session reject if revoked_cert

but the connections still work. I suspect that the ACL are incorrect.


The numbers come from the certificate that I want to reject

$ openssl x509 -in BADCERT.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 37 (0x25)
[...]

$ openssl x509 -in BADCERT.crt -fingerprint
SHA1 
Fingerprint=FC:48:15:01:DB:98:29:0C:5E:9B:22:53:0D:2C:A7:3E:B3:6E:76:C5

[...]


If the error correction is trivial, can someone please tell me what I am 
doing wrong?
Is there some documentation specific to this, maybe with some working 
examples?


Thank you

.marcoc

RE: [PATCHES] 51d: fix warning when building with 51Degrees release version 3.2.12.12

[Ben Shillito]

Hi Willy,

Don't worry, it's an easy mistake.

Yeah, you're absolutely right, my mistake. I assumed that both the URLs were 
"github.com/51degrees", however as the first one is "git.51degrees.com" which 
does indeed contain the deprecated Trie source, you can carry on using 3.2.10 
on this URL. I have attached a patch on top of Dragan's which updates the 
branch name for 3.2.12 and adds instructions for obtaining a free Hash Trie 
data file.

Whilst Trie is still available, I think it is important to make it clear to 
users that, as it uses a lot of memory and was not an optimal solution, the new 
hash based acyclic graph solution (Hash Trie) is the preferred solution. The 
new solution uses 20% of the memory and is 300% faster whilst offering tuning 
options such as difference and drift to avoid over fitting results to the 
training data. The source code folder continues to be named "trie" to maintain 
backwards compatibility in build processes, and source code is public interface 
compatible with prior versions (as implied by Dragan's statement in the readme).

51Degrees are suggesting the small number of Trie users migrate to the new 
version with HAProxy. Any feedback from the HAProxy community would be very 
useful to gauge demand for further updates to the prior Trie data files.

Just to summarise, 3.2.10 on git.51degrees.com/device-detection should be used 
for the old Trie source, and 3.2.12 on github.com/51degrees/device-detection 
should be used for the new Hash Trie source.

Apologies for any confusion.

Regards,

Ben Shillito
Developer
O: +44 1183 287152
E: b...@51degrees.com
T: @51Degrees

-Original Message-
From: Willy TARREAU [mailto:wtarr...@haproxy.com]
Sent: 05 October 2017 17:39
To: Ben Shillito 
Cc: Dragan Dosen ; haproxy@formilux.org
Subject: Re: [PATCHES] 51d: fix warning when building with 51Degrees release 
version 3.2.12.12

On Thu, Oct 05, 2017 at 04:09:09PM +, Ben Shillito wrote:
> Hi Willy,
>
> I have pulled the latest master, but I only see two commits from today. I 
> assume I'm in the right place " http://git.haproxy.org/git/haproxy;?

Argh! Sorry, my fault, I forgot to push :-(

And as stupid as I am I did it to verify so now it's pushed (I could have made 
the changes in place otherwise).

> Using 3.2.10 in 1.7 is fine for Pattern, my only concern is that the
> old Trie source is not available to for users to compile in 3.2.10.

I understood after the latest changes resulting in the public repository being 
erased that what was put back on the download site precisely was everything 
including the Trie that some people were using, but that only the database was 
not updated anymore for the Trie algo (ie: what was running in field would not 
prevent haproxy from being updated and rebuilt). And I thought we even got 
confirmations that it fixed the build issue for them.

> All method signatures in 3.2.12 are unchanged from 3.2.10, so using
> that in 1.7 will not be a problem. If you are more comfortable keeping
> that locked to the fixed 3.2.10, then that is fine,

The principle for our stable versions has always been the same for more than a 
decade : once a new version is released and put into stable state, we don't 
remove features so that users have exactly zero excuse for not updating their 
code within the branch they're using. So if they spent one month validating 
that haproxy 1.7 works and writing deployment scripts to keep it up to date, 
this process shall never fail during all the 1.7 maintenance cycle. This is why 
it's important to maintain the compatibility for something that was emitted. 
However :

  1) it is not a guarantee that it will become better over time (ie in your
 case you provide a database that may or may not be updated, they're
 free to use an outdated one if that suits their needs),

  2) we should always ensure to limit the number of upgrade cycles for our
 users, which means that new adopters who have not yet settled on a
 choice should always be encouraged to pick the most future-proof one.

So in summary, deployments that used to work with 3.2.10 must continue to work 
with it when users simply upgrade their haproxy sources, but those not using it 
yet should prefer 3.2.12.

> but the line of Dragan's statement should  then read something like
> "either use the proven stable but frozen 3.2.10 version which supports
> the Pattern algorithm".

That's the part that's confusing me, because based on our previous discussions 
that was started by Thierry's report of build breakage, I understood that what 
you've put in place ensured it was now OK for them but that they wouldn't 
benefit anymore from updates on the Trie database.
Could you please double-check ?

> Or, if it makes things easier for you, I can backport the
> trie/51Degrees.c/h files to 3.2.10, meaning Trie can be used in that
> version (the Hash Trie files we now distribute will be needed instead of the 
> deprecated