Re: HAProxy and proxy protocol support

Sam Varshavchik <[email protected]> Wed, 12 Jun 2024 08:14:07 -0400

Newsgroups	gmane.mail.imap.courier.general
Message-ID	<[email protected]>

Andrew Athan writes:

> PROXY v1 is indeed easier and should suffice in OP's use case. I would  
> imagine OP (and any other users sophisticated enough to be using HAProxy) can  
> ensure that TCP Fast Open is in use (see "tfo" option on the "backend"  
> stanza). In this case the header should be included in the SYN packet. This  
> should allow you to (perhaps optionally) immediately fail the connection if  
> you cannot read the header bytes with no delay. YMMV given that I haven't  
> tested this explicitly myself, but "tfo" is documented :) A configurable  
> timeout that can be set to 0=drop immediately if no bytes available should do  
> the trick for now, I imagine.

The only fly in the TFO ointment is that on non-SSL connections it is  
vulnerable to TCP retransmissions causing the initial packet's data to be  
seen as duplicated on the server. The new implementation in couriertcpd will  
read and process the first PROXY statement and leave the duplicate one  
unread. This will prove to be catastrophic to SMTP, IMAP, and POP3  
connections.

I'm seriously considering changing all three servers to quietly ignore a  
duplicate PROXY command if they see it. Version 1 has the advantage here, as  
the mitigation is straightforward. This would be much less straightforward  
for version 2.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

signature.asc (application/pgp-signature, 228 B)