Enforcing security with mTLS and long-lived TCP connections

[John Hwang]

Hi folks,

I'm currently working on coming up with some options to implement a security 
requirement that makes it necessary for haproxy to force disconnect any clients 
whose certificate either expires or gets revoked by the CA (via CRL) in midst 
of an active TCP connection.

The simple and "brute-force" method of implementing this would be setting up a 
timeout and forcing the client to reconnect and go through TLS handshake again 
to catch this use case.

However, we also have use cases where the TCP connection can be long lived (eg. 
long-poll/streaming HTTP/gRPC requests and even SSH) and these use cases make 
the brute-force method problematic for the clients if they aren't able to 
gracefully handle disconnects.  On top of that, given the requirement to 
support HTTP/2, renegotiation and post-handshake authentication supported by 
TLSv1.2 and TLSv1.3 respectively would not be possible.

After delving into the haproxy configuration to see if this is something 
haproxy can support out of the box (doesn't seem like it but would love to be 
proved wrong here), my current thought is that this will require creating a 
SPOA that's responsible for keeping track of connection sessions, client 
certificate details like the expiries per session, checking against a CRL, and 
then having the SPOA to use the shutdown session​ runtime API to forcibly 
disconnect a client.

I wanted to ask this to see if there were approaches or tips others had on how 
this use case could be handled.

Thanks in advance!

Re: how to upgrade haproxy

[Aleksandar Lazic]

Hi.


On 2023-08-28 (Mo.) 22:30, Atharva Shripad Dudwadkar wrote:

Hi Haproxy team,

Can we install haproxy using source code in ubuntu 20.04 and how ?


You can follow the Install file to compile HAProxy.

https://git.haproxy.org/?p=haproxy.git;a=blob;f=INSTALL;h=8492a4f37208a6099629101466fec3378a28e73c;hb=HEAD

Regards
Alex

On Thu, 24 Aug 2023 at 4:00 PM, Aleksandar Lazic > wrote:


Hi Atharva Shripad Dudwadkar.

On 2023-08-24 (Do.) 12:08, Willy Tarreau wrote:
 > Hi,
 >
 > On Thu, Aug 24, 2023 at 03:23:59PM +0530, Atharva Shripad
Dudwadkar wrote:
 >> Hi haproxy Team,
 >>
 >> Can you please help me with the upgrading process regarding
haproxy from
 >> 2.0.7 to 2.5. in RHEL. Could you please share with me upgrading
process?
 >
 > Please note that 2.5 is no longer supported, it was a short-lived
 > version. You should consider upgrading to a long term supported one
 > to replace your 2.0, these are 2.4, 2.6 or 2.8. Please look at the
 > packages here for various distros and from various maintainers:
 >
 > https://github.com/haproxy/wiki/wiki/Packages


In addition to that site can you also open a RH Case and ask the Vendor
if there is a updated package, in case you expect some support for the
RHEL package :-).

https://access.redhat.com/support/cases/


 > Regards,
 > Willy

Regards
Alex

--
Sahil Shripad Dudwadkar Sent from iphone

Re: how to upgrade haproxy

[Atharva Shripad Dudwadkar]

Hi Haproxy team,

Can we install haproxy using source code in ubuntu 20.04 and how ?


On Thu, 24 Aug 2023 at 4:00 PM, Aleksandar Lazic  wrote:

> Hi Atharva Shripad Dudwadkar.
>
> On 2023-08-24 (Do.) 12:08, Willy Tarreau wrote:
> > Hi,
> >
> > On Thu, Aug 24, 2023 at 03:23:59PM +0530, Atharva Shripad Dudwadkar
> wrote:
> >> Hi haproxy Team,
> >>
> >> Can you please help me with the upgrading process regarding haproxy from
> >> 2.0.7 to 2.5. in RHEL. Could you please share with me upgrading process?
> >
> > Please note that 2.5 is no longer supported, it was a short-lived
> > version. You should consider upgrading to a long term supported one
> > to replace your 2.0, these are 2.4, 2.6 or 2.8. Please look at the
> > packages here for various distros and from various maintainers:
> >
> >  https://github.com/haproxy/wiki/wiki/Packages
>
> In addition to that site can you also open a RH Case and ask the Vendor
> if there is a updated package, in case you expect some support for the
> RHEL package :-).
>
> https://access.redhat.com/support/cases/
>
> > Regards,
> > Willy
>
> Regards
> Alex
>
-- 
Sahil Shripad Dudwadkar Sent from iphone

Re: Request for feedback: Add support for txn args as arguments in converter "bytes"

[Lokesh Jindal]

Thanks for the response and the corrections, Willy.

*We need to decide what to do when the variable does not*

*exist or is empty. We can't make converters fail for now, so most likelyit
will have to end up as value zero for offset and/or length*.

Here is the implementation today - link
.
We set the length of the output to 0 in case of an invalid input (e.g. arg0
value >= length of the bytes in the input to the converter).
So, for all other invalid inputs (e.g. variable in arg[0] does not exist),
we can do the same.

We can discuss more after I share the patch.

Thanks
Lokesh

On Mon, Aug 28, 2023 at 2:53 AM Willy Tarreau  wrote:

> Hi Lokesh,
>
> On Fri, Aug 25, 2023 at 01:44:48PM -0700, Lokesh Jindal wrote:
> > Hey folks
> >
> > I am writing to gather feedback on an idea before doing the
> implementation.
> > Per the documentation, converter "bytes" accepts integer values as
> > arguments, but not txn args.
> > i.e. ,bytes(2,8) will work
> > but ,bytes(txn.start_idx,txn.length) will not work.
> >
> > For our use case, we need to parse some binary data (a cookie) to extract
> > some info in haproxy. However, the bytes that need to be extracted are
> not
> > fixed and will depend on the request. We could use simple arithmetic to
> > determine the index/length for bytes to be extracted and store them in
> txn
> > args. These txn args can then be used with converter "bytes".
> >
> > I can see that the converter "sub" already supports txn args as
> arguments.
> > I have successfully validated the proposed idea with an implementation
> > following the same pattern as "sub".
>
> In fact it's not "txn", it's variables in general. Most of the arithmetic
> functions support a variable name as an alternative to a numeric value. I
> tend to think it would indeed make sense to support both integers and
> variables for bytes(), it could even be the same for a few other ones
> (maybe field(), word(), ltrim(), rtrim() etc).
>
> > Let me know what you think. If there are no concerns, I can send a patch.
>
> I'm all for it. We need to decide what to do when the variable does not
> exist or is empty. We can't make converters fail for now, so most likely
> it will have to end up as value zero for offset and/or length.
>
> Thanks,
> Willy
>

Content Proposal

[Bash Sarmiento]

Hi there!

I’m Bash Sarmiento, an educator by day and a writer by night. I’m working
on my author credibility this year and luckily, I was able to publish a few
articles here:


   - 8 Tech Courses: Which Self Guided Course Is The Best?
   

   - 5 Leadership Styles To Skyrocket Your Business Growth
   

   - Business Intelligence: Why CFOs Should Have It
   

   - 5 Best Workforce Management Software To Improve Employee Productivity
   


*I was wondering if I could write a unique article for your website, *
haproxy.org,  totally free of charge, so I could add it to my portfolio
once published.


I can also work with your suggestions/preferences.

Just let me know!

I'll wait to hear from you!

Always here!

Cheers,



Bash Sarmiento

Author | Bash Sarmiento Writing



M (+63) 977 607 2702


[image: facebook icon]


[image: instagram icon]


[image: linkedin icon]


The content of this email is confidential and intended for the recipient
specified in the message only. It is strictly forbidden to share any part
of this message with any third party, without a written consent of the
sender. If you received this message by mistake, please reply to this
message and follow with its deletion, so that we can ensure such a mistake
does not occur in the future.


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
ᐧ

RE: [PATCH] MEDIUM: sample: Implement sample fetch for arbitrary PROXY protocol v2 TLV values

[Stephan, Alexander]

Hi Willy,

> finally back to this! Overall it's a great and very clean series, I really 
> want to thank you for this high quality work!
Thanks for the compliment, really glad to hear! :)

> Yeah it initially gave me a bit of head scratching when reading this part but 
> I understood what you did and find that it pretty much makes sense after all.
> It's not necessarily a hack given that what you've done consists in passing a 
> pre-parsed argument internally. It's not much different from the few cases 
> where we emulate older functions or actions using new mechanisms, building 
> some config elements on the fly just to parse them.
Okay, great if there is already similar code. Hack was a bit of an 
overstatement by me, at least if works a bit different than usually.

> I'm fine with this, however I find that the doc is not very clear about what 
> is permitted
I agree that doc needs some more details. I added the note about the iterations 
and described all the symbolic constants, see at the end of this mail.

> Unless you're having any objection, I'm going to flip type and len below:
Sorry, that was an oversight on my end. Sure, go ahead. I actually thought I 
would have arranged it that way, but it somehow slipped my view.

> I tend to *prefer* to have them separately for long series that take a lot of 
> time to review and cannot be done at once. But this series could be reviewed 
> at once, most patches remain small enough so that's no big deal.
OK, great. But I try to keep it in mind for future work anyway.

> In this case it could be clarified in the doc that the sample fetch functions 
> for authority/uniqueid only return the first of each, and that
> fc_pp_tlv() iterates over all occurrences of the requested ID. This would 
> then place a clear separation between trying to extract THE authority, or 
> checking ALL TLVs of type AUTHORITY.

> What do you think ?
Good idea, agreed. That also aligns with my goals to keep the existing behavior 
as much as possible.

> If you're OK with this, I'd appreciate it if you could send a few informal 
> incremental patches that I'd squash into yours.
I'm OK with this. :-) The first patch (0001) should be squashed into the commit 
that introduces the fetch fc_pp_tlv.
I guess it fits there because it actually retains and documents prior behavior. 
The behavior regarding duplicates is also already present,
therefore I already added corresponding docs there.
The second one  (0002) could then be applied to the last patch with the 
introduction of the constants. Would that work for you?

Best,
Alexander


0002-Extend-docs-of-fc_pp_tlv-with-constants.patch
Description: 0002-Extend-docs-of-fc_pp_tlv-with-constants.patch


0001-Restrict-fc_pp_authority-and-fc_pp_unique_id-to-firs.patch
Description:  0001-Restrict-fc_pp_authority-and-fc_pp_unique_id-to-firs.patch

Re: Request for feedback: Add support for txn args as arguments in converter "bytes"

[Willy Tarreau]

Hi Lokesh,

On Fri, Aug 25, 2023 at 01:44:48PM -0700, Lokesh Jindal wrote:
> Hey folks
> 
> I am writing to gather feedback on an idea before doing the implementation.
> Per the documentation, converter "bytes" accepts integer values as
> arguments, but not txn args.
> i.e. ,bytes(2,8) will work
> but ,bytes(txn.start_idx,txn.length) will not work.
> 
> For our use case, we need to parse some binary data (a cookie) to extract
> some info in haproxy. However, the bytes that need to be extracted are not
> fixed and will depend on the request. We could use simple arithmetic to
> determine the index/length for bytes to be extracted and store them in txn
> args. These txn args can then be used with converter "bytes".
> 
> I can see that the converter "sub" already supports txn args as arguments.
> I have successfully validated the proposed idea with an implementation
> following the same pattern as "sub".

In fact it's not "txn", it's variables in general. Most of the arithmetic
functions support a variable name as an alternative to a numeric value. I
tend to think it would indeed make sense to support both integers and
variables for bytes(), it could even be the same for a few other ones
(maybe field(), word(), ltrim(), rtrim() etc).

> Let me know what you think. If there are no concerns, I can send a patch.

I'm all for it. We need to decide what to do when the variable does not
exist or is empty. We can't make converters fail for now, so most likely
it will have to end up as value zero for offset and/or length.

Thanks,
Willy

Re: [PATCH] MEDIUM: sample: Implement sample fetch for arbitrary PROXY protocol v2 TLV values

[Willy Tarreau]

e first authority
return ret;
  }

In this case it could be clarified in the doc that the sample fetch
functions for authority/uniqueid only return the first of each, and that
fc_pp_tlv() iterates over all occurrences of the requested ID. This would
then place a clear separation between trying to extract THE authority, or
checking ALL TLVs of type AUTHORITY.

What do you think ?

If you're OK with this, I'd appreciate it if you could send a few informal
incremental patches that I'd squash into yours. I had to resolve some small
context conflicts by hand so I'd rather keep the branch as-is than take a
new series ;-)  Or alternatively I'm pushing it as "20230828-pp2-tlv-1" if
you prefer to rework it, just do as you prefer, I can adapt.

Thanks!
Willy