You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Amit Pande <Am...@veritas.com.INVALID> on 2023/05/10 16:59:09 UTC
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Thank you, Chris, for the inputs.
Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency which supports the proxy protocol.
Since there is not much action on this https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
Or does it mean that, Tomcat or applications running in Tomcat does not need the remote client address information?
Thanks,
Amit
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, May 8, 2023 3:40 PM
To: users@tomcat.apache.org
Subject: [External] Re: Supporting Proxy Protocol in Tomcat
Amit,
On 5/4/23 16:07, Amit Pande wrote:
> We have a similar requirement as mentioned in the below enhancement request.
>
> https://bz.a/
> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.P
> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4c
> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D&re
> served=0
>
> Is there any plan to add this support in Tomcat in future releases?
Nothing at the moment that I know of.
I thought that markt had looked at this a while back and said it didn't look too difficult. It does require Tomcat to handle the stream directly and not just rely on Java's SSLServerSocket. I thought that had been done at some point, but it may not have. Handling the stream directly may have some other advantages as well, though it definitely makes the code more complicated.
> Also, since this was requested long time back and there is no update,
> are there any other alternatives to pass the client information from
> load balancer to Tomcat in situations where there is no SSL
> termination at load balancer?
You mean like a network load balancer where the lb is just proxying bytes and not looking at the data at all? The PROXY protocol really is the best way to do that, honestly.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Jon,
On 9/4/23 10:41, Jonathan S. Fisher wrote:
> Mark thank you again for your leadership and setting expectations. I'm
> going to commit to working on this with anyone else that wants to help with
> the goal of a patch by year end. I want to nail the patch with minimal
> rework that meets Tomcat project quality standards. To that end, I'll
> attempt to summarize what you expect here and if you could comment and
> correct my understanding that would be appreciated.
>
> It sounds like you're satisfied with the ubiquity of the Proxy protocol and
> that it has an RFC
+1
> We'll target just implementing the latest version of the Proxy protocol
> We'll implement a "TrustedProxies" feature similar to what the Remote IP
> Valve does
+1 This is very important. If it makes sense to do some refactoring to
allow these features to share code, please do that as a completely
separate commit in your PR. It will make things much easier to read and
follow.
> We'll implement a, or modify the RemoteIp, valve to be able to set the
> remote IP from Proxy protocol headers
> We'll follow the RFC spec and reject any request that does a proper Proxy
> protocol header
> I'm particularly interested in the Proxy protocol over Unix Domain Sockets,
> so expect to see a lot of the work focused on this, but accepting Proxy
> Protocol over TCP looks to be quite important from the comments on this
> email chain
TCP is a much more important use-case IMHO.
> If I may ask two things:
> Can you summarize your desired implementation? What point in the stack
> should we target to implement this?
> One thing I'm not familiar with on Tomcat is the testing expectations. If
> you can point to a set of unit tests and a set of integration tests and say
> "Do it like this"
There are tons of unit tests in the Tomcat source tree. IMHO it's much
more important to have /existing/ unit-tests than waiting for a long
time to have "the perfect tests case(s)". If you commit decent
unit-tests and there are opportunities to make them more "Tomcat-like"
or share more code with existing unit-tests, that work can come later.
> Anything else on the original patch you liked/didn't like? (
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
Others know much more about the "right" way to get started on this, so
I'll leave it to them to reply. I wouldn't want to lead you down the
wrong path.
-chris
> On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 28/08/2023 18:44, Amit Pande wrote:
>>> Oh, sure. So, what would be the best way to get some conclusion on this
>> thread?
>>
>> Provide a patch for review based on the feedback provided here and in
>> the BZ issue.
>>
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
>> ticket isn't updated for long. Perhaps add comments/ask the folks on user
>> list to vote?
>>
>> That is more likely to irritate folks rather than encourage them to help
>> you progress your patch.
>>
>> Mark
>>
>>
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Mark Thomas <ma...@apache.org>
>>> Sent: Monday, August 28, 2023 11:20 AM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>>
>>> CAUTION: This email originated from outside the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe. If you believe this is a phishing email, use the
>> Report to Cybersecurity icon in Outlook.
>>>
>>>
>>>
>>> 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
>>>
>>>> Mark,
>>>>
>>>> Just checking - Did this issue get discussed in any of the core
>>>> members' meeting?
>>>
>>> There are no such meetings. Discussion happens on the mailing lists.
>>>
>>> Mark
>>>
>>>
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>> -----Original Message-----
>>>> From: Amit Pande
>>>> Sent: Monday, July 31, 2023 9:29 AM
>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> Yes, understood.
>>>>
>>>> Thank you for clarifying. Even I was referring to initial consensus
>>>> without any timeline or approach conclusion.
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>> -----Original Message-----
>>>> From: Mark Thomas <ma...@apache.org>
>>>> Sent: Friday, July 28, 2023 2:48 PM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> On 28/07/2023 19:21, Amit Pande wrote:
>>>>> Thank you all for the valuable discussion on this topic.
>>>>>
>>>>> Is it okay to say that we're agreeing to adding proxy protocol
>>>>> support in Tomcat?
>>>>
>>>> I think that is a little too strong. At this point there is a proposed
>>>> approach and no one is objecting but until there is an actual patch to
>>>> discuss...
>>>>
>>>> Keep in mind that any committer can veto a change.
>>>>
>>>> My sense is that it should be possible to implement this feature while
>>>> addressing any concerns that may be raised but it is not guaranteed.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Amit
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>> Sent: Thursday, July 27, 2023 4:13 PM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>
>>>>> All,
>>>>>
>>>>> On 7/27/23 12:39, Mark Thomas wrote:
>>>>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>>>>>> On the topic of security, may we consider a trustedProxies setting?
>>>>>>
>>>>>> Seems reasonable.
>>>>>
>>>>> We should probably look at what httpd did for all of this.
>>>>>
>>>>> -chris
>>>>>
>>>>>>> This
>>>>>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>>>>>> It would need to be able to function with APR/NIO listening in a
>>>>>>> Unix Domain Socket.
>>>>>>>
>>>>>>> I'm not sure if this is super useful, but the goal would be an
>>>>>>> added layer of security to prevent Proxy Protocol header injection.
>>>>>>>
>>>>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>>>>>> Mark,
>>>>>>>>>
>>>>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>>>>>> supporting features backed by specifications rather than vendor
>>>>>>>>>> specific hacks.
>>>>>>>>>
>>>>>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>>>>>> nginx,
>>>>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>>>>>> https://ww/
>>>>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
>>>>>>>> s
>>>>>>>> -
>>>>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
>>>>>>>> f
>>>>>>>> a
>>>>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
>>>>>>>> 2
>>>>>>>> 6
>>>>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>>>>>> V
>>>>>>>> 2
>>>>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
>>>>>>>> a
>>>>>>>> 0
>>>>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>>>>>> ).
>>>>>>>>
>>>>>>>> ACK. That reduces my concerns somewhat.
>>>>>>>>
>>>>>>>>> Well, the reality is that people want to use this in the real
>>>>>>>>> world and this is essentially the only way to do it, barring
>>>>>>>>> coming up with a whole new protocol for the purpose (I'm looking
>>>>>>>>> at /you/ AJP!).
>>>>>>>>
>>>>>>>> Indeed.
>>>>>>>>
>>>>>>>>> So why not use /the/ protocol that (a) exists and (b) is
>>>>>>>>> supported by every single product that currently supports this
>>>>>>>>> type of thing?
>>>>>>>>>
>>>>>>>>>> My support for any patch is going to depend on the specifics of
>>>>>>>>>> the patch.
>>>>>>>>>>
>>>>>>>>>> In addition to the comments in the BZ
>>>>>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>>>>>> other
>>>>>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>>>>>> RemoteIpFilter)
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> The whole point of PROXY is to kind of mix-together the
>>>>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>>>>>> headers for
>>>>>>>>> source-information) and the top-level idea of a Connector
>>>>>>>>> (something that binds to a socket and pushes bytes around).
>>>>>>>>>
>>>>>>>>> The confusing thing here is that those two jobs are performed at
>>>>>>>>> relatively different levels in Tomcat at the moment, as I
>>>>>>>>> understand things.
>>>>>>>>
>>>>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>>>>>> higher level because that is where they sit but the data
>>>>>>>> originates from the SocketWrapper.
>>>>>>>>
>>>>>>>>> If some kind of UberConnector could be built which essentially
>>>>>>>>> does something like the following, it would be ideal:
>>>>>>>>>
>>>>>>>>> public void accept(Socket s) {
>>>>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>>>>>
>>>>>>>>> Connector realConnector = getRealConnector();
>>>>>>>>>
>>>>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>>>>>
>>>>>>>>> realConnector.takeItAway(s); }
>>>>>>>>>
>>>>>>>>> I'm sure there are other pieces of information that would be good
>>>>>>>>> to pass-through, but the identity of the remote client is the
>>>>>>>>> most interesting one.
>>>>>>>>
>>>>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
>>>>>>>> use the SocketWrapper rather than the Connector and to do it in a
>>>>>>>> slightly different place. The Acceptor is too early as we want to
>>>>>>>> do as little as possible on the Acceptor thread.
>>>>>>>>
>>>>>>>>>> - needs to be implemented for all Connectors
>>>>>>>>>
>>>>>>>>> I hope not. The connectors should be able to just have a thin
>>>>>>>>> layer in front of them "sipping" the header off the beginning of
>>>>>>>>> the connection.
>>>>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>>>>>> works/should work", but conceptually it "seems easy". That may
>>>>>>>>> not translate into "easy implementation" or it may mean "tons of
>>>>>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>>>>>
>>>>>>>> My point was that the provided patch only implements this for NIO.
>>>>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
>>>>>>>> a lot more difficult to implement and I'd be happy not
>>>>>>>> implementing it for APR/Native.
>>>>>>>>
>>>>>>>>>> - I'd expect it to look more like the SNI processing
>>>>>>>>>
>>>>>>>>> SNI processing is very connector-dependent, of course, because
>>>>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
>>>>>>>>> anything.
>>>>>>>>> So if it can be implemented as something that can just "sit in
>>>>>>>>> front of"
>>>>>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>>>>>> done separately and globally.
>>>>>>>>
>>>>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>>>>>
>>>>>>>> SNI is handled independently of implementation and I think PROXY
>>>>>>>> should be handled the same way. They also sit at almost the same
>>>>>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>>>>>> could be implemented within the existing handshake() method but I
>>>>>>>> think it would be much cleaner in a separate method.
>>>>>>>>
>>>>>>>> Without looking at it too closely I think the implementation would
>>>>>>>> look something like:
>>>>>>>>
>>>>>>>> - a new method on SocketWrapperBase that
>>>>>>>> - checks if PROXY is enabled
>>>>>>>> - returns immediately if PROXY is not enabled or has already
>>>>>>>> been parsed
>>>>>>>> - uses a new utility class (or classes) to parse the header
>>>>>>>> (reading via the read() methods on SocketWrapperBase)
>>>>>>>> - sets the cached values for remoteAddr, remoteHost,
>>>>>>>> remotePort etc
>>>>>>>> - The SocketProcessor.doRun() implementations add a call to this
>>>>>>>> new
>>>>>>>> method just before the TLS handshake
>>>>>>>>
>>>>>>>> If we want to support the TLS information then a little additional
>>>>>>>> refactoring will be required (probably to cache the result of
>>>>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>>>>>> insert a PROXY specific SSLSupport implementation.
>>>>>>>>
>>>>>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
>>>>>>>>> it!"
>>>>>>>>> :)
>>>>>>>>
>>>>>>>> :)
>>>>>>>>
>>>>>>>> Actually with the patch that has already been provided and the
>>>>>>>> suggested implementation outline above I don't think there is too
>>>>>>>> much work to do.
>>>>>>>>
>>>>>>>>>> Generally, I don't think implementing this is going to be
>>>>>>>>>> possible as some sort of plug-in.
>>>>>>>>>
>>>>>>>>> +1 Unless the plug-in is "a whole new set of
>>>>>>>>> protocol/endpoint/etc.
>>>>>>>>> handlers" which is a rather serious commitment.
>>>>>>>>
>>>>>>>> On reflection, with the approach above we probably could implement
>>>>>>>> this via a new plug-in framework but I am not sure it is worth the
>>>>>>>> effort at this point. Something to keep in mind if we have more
>>>>>>>> things wanting to integrate at this point in the processing chain.
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>> Fhttpd.apache.org
>> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
>> 40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0
>> search for "haproxy"
>>>>>>>>>
>>>>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>>>>>> Missed to ask this:
>>>>>>>>>>>
>>>>>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>>>>>> protocol
>>>>>>>> support?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amit
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Amit Pande
>>>>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>
>>>>>>>>>>> Chris, Mark,
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts on this?
>>>>>>>>>>>
>>>>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>>>>>> any concerns (specially security wise)?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amit
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>
>>>>>>>>>>> Just a side note, because we're also very interested in this
>>>>>>>>>>> patch!
>>>>>>>>>>>
>>>>>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
>>>>>>>>>>> the relevant/required information to tomcat. I believe we had
>>>>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
>>>>>>>>>>> patch didn't handle that case.
>>>>>>>>>>>
>>>>>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>>>>>> getting a significant boost in throughput and decrease in
>>>>>>>>>>> latency.
>>>>>>>>>>>
>>>>>>>>>>> +1 for this patch and willing to help out!
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>>>>>> <Am...@veritas.com.invalid>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>>>>>
>>>>>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>>>>>> attached in
>>>>>>>>>>>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0
>> ?
>>>>>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>>>>>
>>>>>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Amit
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
>>>>>>>>>>>> Tomcat
>>>>>>>>>>>>
>>>>>>>>>>>> Amit,
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
>>>>>>>>>>>>> TCP proxy e.g.
>>>>>>>>>>>>>
>>>>>>>>>>>> https://www/.
>>>>>>>>>>>> envoyproxy.io
>>>>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>>>>>> c
>>>>>>>>>>>> om
>>>>>>>> %7Ca
>>>>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
>>>>>>>>>>>> a
>>>>>>>>>>>> c
>>>>>>>>>>>> 32%7C0
>>>>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>>>>>>> L
>>>>>>>>>>>> j
>>>>>>>>>>>> AwMDAi
>>>>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>>>> &
>>>>>>>>>>>> s
>>>>>>>>>>>> data=W
>>>>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>>>>>> which supports the proxy protocol.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since there is not much action on this
>>>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
>>>>>>>>>>>> F
>>>>>>>>>>>> %25
>>>>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
>>>>>>>>>>>> c
>>>>>>>>>>>> 1
>>>>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
>>>>>>>>>>>> 0
>>>>>>>>>>>> %
>>>>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>>>>> D
>>>>>>>>>>>> A
>>>>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>>>>>>>>>>>> C
>>>>>>>>>>>> &
>>>>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
>>>>>>>>>>>> 0
>>>>>>>>>>>> pache.org
>>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
>>>>>>>> 5
>>>>>>>> b
>>>>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
>>>>>>>> 3
>>>>>>>> d
>>>>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>> D
>>>>>>>> %
>>>>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
>>>>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
>>>>>>>> is running behind HTTP proxies and not TCP proxies?
>>>>>>>>>>>>> Or does it mean that, Tomcat or applications running in
>>>>>>>>>>>>> Tomcat does not
>>>>>>>>>>>> need the remote client address information?
>>>>>>>>>>>>
>>>>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>>>>>
>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>> -chris
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>>>
>>>>>>>>>>>>> Amit,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>>>>>> enhancement
>>>>>>>>>>>> request.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://bz/.
>>>>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4
>>>>>>>>>>>>>> b
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> 87206
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
>>>>>>>>>>>>>> 9
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> 50613
>>>>>>>>>>>>>> 56
>>>>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>>>>>>>>>>>> l
>>>>>>>>>>>>>> u
>>>>>>>>>>>>>> MzIiL
>>>>>>>>>>>>>> CJ
>>>>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
>>>>>>>>>>>>>> t
>>>>>>>>>>>>>> L
>>>>>>>>>>>>>> qUzY9
>>>>>>>>>>>>>> JM
>>>>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>>>>>> pache.org
>>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>>>>>> P
>>>>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> c0422
>>>>>>>>>>>>>> c4
>>>>>>>>>>>>>> c
>>>>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
>>>>>>>>>>>>>> T
>>>>>>>>>>>>>> W
>>>>>>>>>>>>>> FpbGZ
>>>>>>>>>>>>>> sb
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>> Mn0%3
>>>>>>>>>>>>>> D%
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
>>>>>>>>>>>>>> l
>>>>>>>>>>>>>> 4
>>>>>>>>>>>>>> mY%3D
>>>>>>>>>>>>>> &r
>>>>>>>>>>>>>> e
>>>>>>>>>>>>>> served=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>>>>>> releases?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>>>>>> it didn't
>>>>>>>>>>>> look too difficult. It does require Tomcat to handle the
>>>>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
>>>>>>>>>>>> thought that had been done at some point, but it may not have.
>>>>>>>>>>>> Handling the stream directly may have some other advantages as
>>>>>>>>>>>> well, though it definitely makes the code more complicated.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, since this was requested long time back and there is
>>>>>>>>>>>>>> no update, are there any other alternatives to pass the
>>>>>>>>>>>>>> client information from load balancer to Tomcat in
>>>>>>>>>>>>>> situations where there is no SSL termination at load balancer?
>>>>>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>>>>>> proxying
>>>>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -chris
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>> -
>>>>>>>>>>>> -
>>>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>> -
>>>>>>>>>>>> -
>>>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
>>>>>>>>>>> see it as half full.
>>>>>>>>>>> Engineers, of course, understand the glass is twice as big as
>>>>>>>>>>> it needs to be.
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> ---- To unsubscribe, e-mail:
>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Thank you, Jonathan, for updating this thread.
I was thinking of cleaning up the existing patch and submit it for review.
I agree it's better to get feedback before any work is started.
Thanks,
Amit
-----Original Message-----
From: Jonathan S. Fisher <ex...@gmail.com>
Sent: Monday, September 4, 2023 9:42 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook.
Mark thank you again for your leadership and setting expectations. I'm going to commit to working on this with anyone else that wants to help with the goal of a patch by year end. I want to nail the patch with minimal rework that meets Tomcat project quality standards. To that end, I'll attempt to summarize what you expect here and if you could comment and correct my understanding that would be appreciated.
It sounds like you're satisfied with the ubiquity of the Proxy protocol and that it has an RFC We'll target just implementing the latest version of the Proxy protocol We'll implement a "TrustedProxies" feature similar to what the Remote IP Valve does We'll implement a, or modify the RemoteIp, valve to be able to set the remote IP from Proxy protocol headers We'll follow the RFC spec and reject any request that does a proper Proxy protocol header I'm particularly interested in the Proxy protocol over Unix Domain Sockets, so expect to see a lot of the work focused on this, but accepting Proxy Protocol over TCP looks to be quite important from the comments on this email chain
If I may ask two things:
Can you summarize your desired implementation? What point in the stack should we target to implement this?
One thing I'm not familiar with on Tomcat is the testing expectations. If you can point to a set of unit tests and a set of integration tests and say "Do it like this"
Anything else on the original patch you liked/didn't like? (
https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
Thank you,
On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> On 28/08/2023 18:44, Amit Pande wrote:
> > Oh, sure. So, what would be the best way to get some conclusion on
> > this
> thread?
>
> Provide a patch for review based on the feedback provided here and in
> the BZ issue.
>
> > https://bz/
> > .apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAm
> > it.Pande%40veritas.com%7Cead161f45fdf4f7ae40808dbad552039%7Cfc8e13c0
> > 422c4c55b3eaca318e6cac32%7C0%7C0%7C638294353363138987%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> > I6Mn0%3D%7C3000%7C%7C%7C&sdata=UPENCoX0wXwqKw4L96w9PfNxSvh%2FzItbDGg
> > uwsdMlqY%3D&reserved=0 The state of the
> ticket isn't updated for long. Perhaps add comments/ask the folks on
> user list to vote?
>
> That is more likely to irritate folks rather than encourage them to
> help you progress your patch.
>
> Mark
>
>
> >
> > Thanks,
> > Amit
> >
> > -----Original Message-----
> > From: Mark Thomas <ma...@apache.org>
> > Sent: Monday, August 28, 2023 11:20 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> >
> > CAUTION: This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and
> know the content is safe. If you believe this is a phishing email, use
> the Report to Cybersecurity icon in Outlook.
> >
> >
> >
> > 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> >
> >> Mark,
> >>
> >> Just checking - Did this issue get discussed in any of the core
> >> members' meeting?
> >
> > There are no such meetings. Discussion happens on the mailing lists.
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >> Amit
> >>
> >> -----Original Message-----
> >> From: Amit Pande
> >> Sent: Monday, July 31, 2023 9:29 AM
> >> To: Tomcat Users List <us...@tomcat.apache.org>
> >> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> Yes, understood.
> >>
> >> Thank you for clarifying. Even I was referring to initial consensus
> >> without any timeline or approach conclusion.
> >>
> >> Thanks,
> >> Amit
> >>
> >> -----Original Message-----
> >> From: Mark Thomas <ma...@apache.org>
> >> Sent: Friday, July 28, 2023 2:48 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> On 28/07/2023 19:21, Amit Pande wrote:
> >>> Thank you all for the valuable discussion on this topic.
> >>>
> >>> Is it okay to say that we're agreeing to adding proxy protocol
> >>> support in Tomcat?
> >>
> >> I think that is a little too strong. At this point there is a
> >> proposed approach and no one is objecting but until there is an
> >> actual patch to discuss...
> >>
> >> Keep in mind that any committer can veto a change.
> >>
> >> My sense is that it should be possible to implement this feature
> >> while addressing any concerns that may be raised but it is not guaranteed.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -----Original Message-----
> >>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>> Sent: Thursday, July 27, 2023 4:13 PM
> >>> To: users@tomcat.apache.org
> >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> All,
> >>>
> >>> On 7/27/23 12:39, Mark Thomas wrote:
> >>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
> >>>>> On the topic of security, may we consider a trustedProxies setting?
> >>>>
> >>>> Seems reasonable.
> >>>
> >>> We should probably look at what httpd did for all of this.
> >>>
> >>> -chris
> >>>
> >>>>> This
> >>>>> would be an analog to the internalProxies setting on RemoteIpValve.
> >>>>> It would need to be able to function with APR/NIO listening in a
> >>>>> Unix Domain Socket.
> >>>>>
> >>>>> I'm not sure if this is super useful, but the goal would be an
> >>>>> added layer of security to prevent Proxy Protocol header injection.
> >>>>>
> >>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
> >>>>>>> Mark,
> >>>>>>>
> >>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
> >>>>>>>> I'm not a huge fan of this feature in general. I prefer
> >>>>>>>> supporting features backed by specifications rather than
> >>>>>>>> vendor specific hacks.
> >>>>>>>
> >>>>>>> I think the PROXY protocol is fairly standard, even if it's
> >>>>>>> not backed by an RFC. It's published by haproxy, but supported
> >>>>>>> by nginx,
> >>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of
> >>>>>>> others (
> >>>>>> https://ww/
> >>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-cli
> >>>>>> ent
> >>>>>> s
> >>>>>> -
> >>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
> >>>>>> c14
> >>>>>> f
> >>>>>> a
> >>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C
> >>>>>> 638
> >>>>>> 2
> >>>>>> 6
> >>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> >>>>>> joi
> >>>>>> V
> >>>>>> 2
> >>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHW
> >>>>>> pIL
> >>>>>> a
> >>>>>> 0
> >>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
> >>>>>> ).
> >>>>>>
> >>>>>> ACK. That reduces my concerns somewhat.
> >>>>>>
> >>>>>>> Well, the reality is that people want to use this in the real
> >>>>>>> world and this is essentially the only way to do it, barring
> >>>>>>> coming up with a whole new protocol for the purpose (I'm
> >>>>>>> looking at /you/ AJP!).
> >>>>>>
> >>>>>> Indeed.
> >>>>>>
> >>>>>>> So why not use /the/ protocol that (a) exists and (b) is
> >>>>>>> supported by every single product that currently supports this
> >>>>>>> type of thing?
> >>>>>>>
> >>>>>>>> My support for any patch is going to depend on the specifics
> >>>>>>>> of the patch.
> >>>>>>>>
> >>>>>>>> In addition to the comments in the BZ
> >>>>>>>> - exposing the data as a request attribute is inconsistent
> >>>>>>>> with other
> >>>>>>>> mechanisms that solve the same problem (e.g. see
> >>>>>>>> RemoteIpFilter)
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> The whole point of PROXY is to kind of mix-together the
> >>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
> >>>>>>> headers for
> >>>>>>> source-information) and the top-level idea of a Connector
> >>>>>>> (something that binds to a socket and pushes bytes around).
> >>>>>>>
> >>>>>>> The confusing thing here is that those two jobs are performed
> >>>>>>> at relatively different levels in Tomcat at the moment, as I
> >>>>>>> understand things.
> >>>>>>
> >>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
> >>>>>> higher level because that is where they sit but the data
> >>>>>> originates from the SocketWrapper.
> >>>>>>
> >>>>>>> If some kind of UberConnector could be built which essentially
> >>>>>>> does something like the following, it would be ideal:
> >>>>>>>
> >>>>>>> public void accept(Socket s) {
> >>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
> >>>>>>>
> >>>>>>> Connector realConnector = getRealConnector();
> >>>>>>>
> >>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> >>>>>>>
> >>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
> >>>>>>>
> >>>>>>> realConnector.takeItAway(s); }
> >>>>>>>
> >>>>>>> I'm sure there are other pieces of information that would be
> >>>>>>> good to pass-through, but the identity of the remote client is
> >>>>>>> the most interesting one.
> >>>>>>
> >>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
> >>>>>> use the SocketWrapper rather than the Connector and to do it in
> >>>>>> a slightly different place. The Acceptor is too early as we
> >>>>>> want to do as little as possible on the Acceptor thread.
> >>>>>>
> >>>>>>>> - needs to be implemented for all Connectors
> >>>>>>>
> >>>>>>> I hope not. The connectors should be able to just have a thin
> >>>>>>> layer in front of them "sipping" the header off the beginning
> >>>>>>> of the connection.
> >>>>>>> I am *way* out of my depth here when it comes to Tomcat
> >>>>>>> internals and so I don't want to appear to be telling you
> >>>>>>> (Mark) "how it works/should work", but conceptually it "seems
> >>>>>>> easy". That may not translate into "easy implementation" or it
> >>>>>>> may mean "tons of refactoring that we wouldn't need if we didn't care that much."
> >>>>>>
> >>>>>> My point was that the provided patch only implements this for NIO.
> >>>>>> It needs to implement it for NIO2 as well. APR/Native looks to
> >>>>>> be a lot more difficult to implement and I'd be happy not
> >>>>>> implementing it for APR/Native.
> >>>>>>
> >>>>>>>> - I'd expect it to look more like the SNI processing
> >>>>>>>
> >>>>>>> SNI processing is very connector-dependent, of course, because
> >>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP,
> >>>>>>> JDBC, anything.
> >>>>>>> So if it can be implemented as something that can just "sit in
> >>>>>>> front of"
> >>>>>>> *any* connector now or in the future of Tomcat, that would be
> >>>>>>> ideal. It could definitely be implemented as an "optional feature"
> >>>>>>> on a Connector-by-Connector basis, but my sense is that it can
> >>>>>>> be done separately and globally.
> >>>>>>
> >>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
> >>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
> >>>>>>
> >>>>>> SNI is handled independently of implementation and I think
> >>>>>> PROXY should be handled the same way. They also sit at almost
> >>>>>> the same point in the processing (PROXY needs to be first).
> >>>>>> PROXY parsing could be implemented within the existing
> >>>>>> handshake() method but I think it would be much cleaner in a separate method.
> >>>>>>
> >>>>>> Without looking at it too closely I think the implementation
> >>>>>> would look something like:
> >>>>>>
> >>>>>> - a new method on SocketWrapperBase that
> >>>>>> - checks if PROXY is enabled
> >>>>>> - returns immediately if PROXY is not enabled or has already
> >>>>>> been parsed
> >>>>>> - uses a new utility class (or classes) to parse the header
> >>>>>> (reading via the read() methods on SocketWrapperBase)
> >>>>>> - sets the cached values for remoteAddr, remoteHost,
> >>>>>> remotePort etc
> >>>>>> - The SocketProcessor.doRun() implementations add a call to
> >>>>>> this new
> >>>>>> method just before the TLS handshake
> >>>>>>
> >>>>>> If we want to support the TLS information then a little
> >>>>>> additional refactoring will be required (probably to cache the
> >>>>>> result of
> >>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
> >>>>>> insert a PROXY specific SSLSupport implementation.
> >>>>>>
> >>>>>>> Again, I'm speaking from a position of profound ignorance, here.
> >>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
> >>>>>>> it!"
> >>>>>>> :)
> >>>>>>
> >>>>>> :)
> >>>>>>
> >>>>>> Actually with the patch that has already been provided and the
> >>>>>> suggested implementation outline above I don't think there is
> >>>>>> too much work to do.
> >>>>>>
> >>>>>>>> Generally, I don't think implementing this is going to be
> >>>>>>>> possible as some sort of plug-in.
> >>>>>>>
> >>>>>>> +1 Unless the plug-in is "a whole new set of
> >>>>>>> protocol/endpoint/etc.
> >>>>>>> handlers" which is a rather serious commitment.
> >>>>>>
> >>>>>> On reflection, with the approach above we probably could
> >>>>>> implement this via a new plug-in framework but I am not sure it
> >>>>>> is worth the effort at this point. Something to keep in mind if
> >>>>>> we have more things wanting to integrate at this point in the processing chain.
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>>
> >>>>>>> -chris
> >>>>>>>
> >>>>>>> [1]
> >>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%252
> >>>>>>> F%2
> >>>>>>> Fhttpd.apache.org
> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
> 40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3e
> aca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&res
> erved=0
> search for "haproxy"
> >>>>>>>
> >>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
> >>>>>>>>> Missed to ask this:
> >>>>>>>>>
> >>>>>>>>> Looking the patch, it involves modifying Tomcat code.
> >>>>>>>>> Was wondering if it would be possible to refactor this patch
> >>>>>>>>> and/or allow Tomcat core code to extend and plug-in the
> >>>>>>>>> proxy protocol
> >>>>>> support?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Amit
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Amit Pande
> >>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
> >>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>> Tomcat
> >>>>>>>>>
> >>>>>>>>> Chris, Mark,
> >>>>>>>>>
> >>>>>>>>> Any thoughts on this?
> >>>>>>>>>
> >>>>>>>>> Mark, if we clean up the patch and re-submit, do you will
> >>>>>>>>> have any concerns (specially security wise)?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Amit
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
> >>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
> >>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>> Tomcat
> >>>>>>>>>
> >>>>>>>>> Just a side note, because we're also very interested in this
> >>>>>>>>> patch!
> >>>>>>>>>
> >>>>>>>>> Awhile back, I was successfully able to apply this patch and
> >>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen
> >>>>>>>>> on a unix domain socket and the Proxy protocol provided
> >>>>>>>>> *most *of the relevant/required information to tomcat. I
> >>>>>>>>> believe we had to add a Valve to tomcat to set the Remote IP
> >>>>>>>>> however as the patch didn't handle that case.
> >>>>>>>>>
> >>>>>>>>> I can find my notes from that experiment, but I do remember
> >>>>>>>>> getting a significant boost in throughput and decrease in
> >>>>>>>>> latency.
> >>>>>>>>>
> >>>>>>>>> +1 for this patch and willing to help out!
> >>>>>>>>>
> >>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> >>>>>>>>> <Am...@veritas.com.invalid>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thank you, Chris, again for inputs.
> >>>>>>>>>> And sorry to circle back on this, late.
> >>>>>>>>>>
> >>>>>>>>>> One related question is - does it make sense to use the
> >>>>>>>>>> patch attached in
> >>>>>>>>>>
> https://bz.a/
> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.P
> ande%40veritas.com%7Cead161f45fdf4f7ae40808dbad552039%7Cfc8e13c0422c4c
> 55b3eaca318e6cac32%7C0%7C0%7C638294353363138987%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=UPENCoX0wXwqKw4L96w9PfNxSvh%2FzItbDGguwsdMlqY%3D&
> reserved=0
> ?
> >>>>>>>>>> And potentially, get it integrated into Tomcat versions?
> >>>>>>>>>>
> >>>>>>>>>> There are concerns from Mark about using the patch in its
> >>>>>>>>>> current state, but I see last comment (#24) on the issue
> >>>>>>>>>> and looks like there are some more points to be concluded.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Amit
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
> >>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>>> Tomcat
> >>>>>>>>>>
> >>>>>>>>>> Amit,
> >>>>>>>>>>
> >>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
> >>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
> >>>>>>>>>>> TCP proxy e.g.
> >>>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> envoyproxy.io
> >>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> >>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
> >>>>>>>>>> c
> >>>>>>>>>> om
> >>>>>> %7Ca
> >>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318
> >>>>>>>>>> e6c
> >>>>>>>>>> a
> >>>>>>>>>> c
> >>>>>>>>>> 32%7C0
> >>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> >>>>>>>>>> C4w
> >>>>>>>>>> L
> >>>>>>>>>> j
> >>>>>>>>>> AwMDAi
> >>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> >>>>>>>>>> %7C
> >>>>>>>>>> &
> >>>>>>>>>> s
> >>>>>>>>>> data=W
> >>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> >>>>>>>>>> which supports the proxy protocol.
> >>>>>>>>>>>
> >>>>>>>>>>> Since there is not much action on this
> >>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%253
> >>>>>>>>>> A%2
> >>>>>>>>>> F
> >>>>>>>>>> %25
> >>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5
> >>>>>>>>>> eea
> >>>>>>>>>> c
> >>>>>>>>>> 1
> >>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
> >>>>>>>>>> %7C
> >>>>>>>>>> 0
> >>>>>>>>>> %
> >>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> >>>>>>>>>> AwM
> >>>>>>>>>> D
> >>>>>>>>>> A
> >>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> >>>>>>>>>> C%7
> >>>>>>>>>> C
> >>>>>>>>>> &
> >>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserv
> >>>>>>>>>> ed=
> >>>>>>>>>> 0
> >>>>>>>>>> pache.org
> >>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pan
> >>>>>> de%
> >>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c
> >>>>>> 4c5
> >>>>>> 5
> >>>>>> b
> >>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbG
> >>>>>> Zsb
> >>>>>> 3
> >>>>>> d
> >>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> >>>>>> 0%3
> >>>>>> D
> >>>>>> %
> >>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnL
> >>>>>> feh X v Q%3D&reserved=0, does it imply that most of the times
> >>>>>> Tomcat is running behind HTTP proxies and not TCP proxies?
> >>>>>>>>>>> Or does it mean that, Tomcat or applications running in
> >>>>>>>>>>> Tomcat does not
> >>>>>>>>>> need the remote client address information?
> >>>>>>>>>>
> >>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as
> >>>>>>>>>> my reverse-proxy and I do terminate TLS. I also use it for
> >>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc.
> >>>>>>>>>> I wouldn't be able to use a TCP load-balancer because I
> >>>>>>>>>> hide multiple services behind my reverse-proxy which run in
> >>>>>>>>>> different places. It's not just s dumb pass-through.
> >>>>>>>>>>
> >>>>>>>>>> Hope that helps,
> >>>>>>>>>> -chris
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
> >>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>>>> Tomcat
> >>>>>>>>>>>
> >>>>>>>>>>> Amit,
> >>>>>>>>>>>
> >>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
> >>>>>>>>>>>> We have a similar requirement as mentioned in the below
> >>>>>>>>>>>> enhancement
> >>>>>>>>>> request.
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://bz/.
> >>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927
> >>>>>>>>>>>> ed4
> >>>>>>>>>>>> b
> >>>>>>>>>>>> 7
> >>>>>>>>>>>> 87206
> >>>>>>>>>>>> 08
> >>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6
> >>>>>>>>>>>> 381
> >>>>>>>>>>>> 9
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> 50613
> >>>>>>>>>>>> 56
> >>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> >>>>>>>>>>>> iV2
> >>>>>>>>>>>> l
> >>>>>>>>>>>> u
> >>>>>>>>>>>> MzIiL
> >>>>>>>>>>>> CJ
> >>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ
> >>>>>>>>>>>> 9Zg
> >>>>>>>>>>>> t
> >>>>>>>>>>>> L
> >>>>>>>>>>>> qUzY9
> >>>>>>>>>>>> JM
> >>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >>>>>>>>>>>> pache.org
> >>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >>>>>>>>>>>> P
> >>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cf
> >>>>>>>>>>>> c8e
> >>>>>>>>>>>> 1
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> c0422
> >>>>>>>>>>>> c4
> >>>>>>>>>>>> c
> >>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown
> >>>>>>>>>>>> %7C
> >>>>>>>>>>>> T
> >>>>>>>>>>>> W
> >>>>>>>>>>>> FpbGZ
> >>>>>>>>>>>> sb
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> >>>>>>>>>>>> XVC
> >>>>>>>>>>>> I
> >>>>>>>>>>>> 6
> >>>>>>>>>>>> Mn0%3
> >>>>>>>>>>>> D%
> >>>>>>>>>>>> 7
> >>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V
> >>>>>>>>>>>> 3nO
> >>>>>>>>>>>> l
> >>>>>>>>>>>> 4
> >>>>>>>>>>>> mY%3D
> >>>>>>>>>>>> &r
> >>>>>>>>>>>> e
> >>>>>>>>>>>> served=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
> >>>>>>>>>>>> releases?
> >>>>>>>>>>>
> >>>>>>>>>>> Nothing at the moment that I know of.
> >>>>>>>>>>>
> >>>>>>>>>>> I thought that markt had looked at this a while back and
> >>>>>>>>>>> said it didn't
> >>>>>>>>>> look too difficult. It does require Tomcat to handle the
> >>>>>>>>>> stream directly and not just rely on Java's
> >>>>>>>>>> SSLServerSocket. I thought that had been done at some point, but it may not have.
> >>>>>>>>>> Handling the stream directly may have some other advantages
> >>>>>>>>>> as well, though it definitely makes the code more complicated.
> >>>>>>>>>>>
> >>>>>>>>>>>> Also, since this was requested long time back and there
> >>>>>>>>>>>> is no update, are there any other alternatives to pass
> >>>>>>>>>>>> the client information from load balancer to Tomcat in
> >>>>>>>>>>>> situations where there is no SSL termination at load balancer?
> >>>>>>>>>>> You mean like a network load balancer where the lb is just
> >>>>>>>>>>> proxying
> >>>>>>>>>> bytes and not looking at the data at all? The PROXY
> >>>>>>>>>> protocol really is the best way to do that, honestly.
> >>>>>>>>>>>
> >>>>>>>>>>> -chris
> >>>>>>>>>>>
> >>>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>>> ---
> >>>>>>>>>>> -
> >>>>>>>>>>> -
> >>>>>>>>>>> -----
> >>>>>>>>>>> - To unsubscribe, e-mail:
> >>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ----------------------------------------------------------
> >>>>>>>>>>> ---
> >>>>>>>>>>> -
> >>>>>>>>>>> -
> >>>>>>>>>>> -----
> >>>>>>>>>>> - To unsubscribe, e-mail:
> >>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -----------------------------------------------------------
> >>>>>>>>>> ---
> >>>>>>>>>> -
> >>>>>>>>>> -
> >>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -----------------------------------------------------------
> >>>>>>>>>> ---
> >>>>>>>>>> -
> >>>>>>>>>> -
> >>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Jonathan | exabrial@gmail.com Pessimists, see a jar as half
> >>>>>>>>> empty. Optimists, in contrast, see it as half full.
> >>>>>>>>> Engineers, of course, understand the glass is twice as big
> >>>>>>>>> as it needs to be.
> >>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> ---
> >>>>>>>>> -
> >>>>>>>>> -
> >>>>>>>>> ---- To unsubscribe, e-mail:
> >>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>> For additional commands, e-mail:
> >>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> -------------------------------------------------------------
> >>>>>>>> ---
> >>>>>>>> -
> >>>>>>>> -
> >>>>>>>> --- To unsubscribe, e-mail:
> >>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>>>> ---
> >>>>>>> -
> >>>>>>> -
> >>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------
> >>>>>> ---
> >>>>>> -
> >>>>>> -
> >>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> -----------------------------------------------------------------
> >>>> ---
> >>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>
> >>> ------------------------------------------------------------------
> >>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>> ------------------------------------------------------------------
> >>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full.
Engineers, of course, understand the glass is twice as big as it needs to be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
Hello Adwait,
I originally was going to sponsor this to get it done before year end.
Unfortunately my timeline got pushed to 2024 as we found a more
impactful area to make performance improvements. It's still a very
valuable and important Tomcat feature. The original PR is a good
starting place, and needs Mark's feedback implemented along with the
discussion notes I sent a few months back. After that, some tests
written to check for edge cases, especially around protocol parsing.
On Tue, Nov 21, 2023 at 3:56 PM Adwait Kumar Singh <ad...@gmail.com> wrote:
>
> Hey,
>
> Checking in on this thread. Is someone actively working on this?
>
> I am more than happy to contribute/help in any way to move this forward
> quickly.
>
>
> Thanks,
> Adwait.
>
> On Tue, Sep 5, 2023 at 1:11 PM Mark Thomas <ma...@apache.org> wrote:
>
> > On 04/09/2023 15:41, Jonathan S. Fisher wrote:
> > > Mark thank you again for your leadership and setting expectations. I'm
> > > going to commit to working on this with anyone else that wants to help
> > with
> > > the goal of a patch by year end. I want to nail the patch with minimal
> > > rework that meets Tomcat project quality standards. To that end, I'll
> > > attempt to summarize what you expect here and if you could comment and
> > > correct my understanding that would be appreciated.
> > >
> > > It sounds like you're satisfied with the ubiquity of the Proxy protocol
> > and
> > > that it has an RFC
> > > We'll target just implementing the latest version of the Proxy protocol
> > > We'll implement a "TrustedProxies" feature similar to what the Remote IP
> > > Valve does
> > > We'll implement a, or modify the RemoteIp, valve to be able to set the
> > > remote IP from Proxy protocol headers
> > > We'll follow the RFC spec and reject any request that does a proper Proxy
> > > protocol header
> > > I'm particularly interested in the Proxy protocol over Unix Domain
> > Sockets,
> > > so expect to see a lot of the work focused on this, but accepting Proxy
> > > Protocol over TCP looks to be quite important from the comments on this
> > > email chain
> > >
> > > If I may ask two things:
> > > Can you summarize your desired implementation? What point in the stack
> > > should we target to implement this?
> >
> > See my response earlier in this thread that suggested it sits alongside
> > SNI processing. I still think that makes sense. If during implementation
> > you reach a different conclusion then make the case for the alternative
> > approach on list.
> >
> > > One thing I'm not familiar with on Tomcat is the testing expectations. If
> > > you can point to a set of unit tests and a set of integration tests and
> > say
> > > "Do it like this"
> >
> > Something like (only a guide)
> >
> >
> > https://github.com/apache/tomcat/blob/main/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
> >
> > to test the implementation directly and probably something based on
> > SimpleHttpClient see
> >
> >
> > https://github.com/apache/tomcat/blob/main/test/org/apache/coyote/http11/TestHttp11Processor.java
> >
> > for various examples. The main thing is I suspect you'll need control of
> > the individual bytes and SimpleHttpClient provides a reasonably simple
> > basis for that.
> >
> > What we often do when we want to test things like setting remote IP
> > addresses etc. is echo the value in the response body and then check
> > that value in the client.
> >
> > > Anything else on the original patch you liked/didn't like? (
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
> >
> > It helps if you enable Checkstyle for your local build. It helps keep
> > things in roughly the same coding style (we are slowly tightening up on
> > that). Ideally, use the clean-up and formatting configurations we have
> > for Eclipse in res/ide-support/eclipse .
> >
> > This is sufficiently complex that I am expecting several iterations to
> > be required. if it is simpler for you to manage with a PR then that is
> > fine and probably easier to work with than a patch in Bugzilla.
> >
> > Mark
> >
> > >
> > > Thank you,
> > >
> > >
> > > On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> > >
> > >> On 28/08/2023 18:44, Amit Pande wrote:
> > >>> Oh, sure. So, what would be the best way to get some conclusion on this
> > >> thread?
> > >>
> > >> Provide a patch for review based on the feedback provided here and in
> > >> the BZ issue.
> > >>
> > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
> > >> ticket isn't updated for long. Perhaps add comments/ask the folks on
> > user
> > >> list to vote?
> > >>
> > >> That is more likely to irritate folks rather than encourage them to help
> > >> you progress your patch.
> > >>
> > >> Mark
> > >>
> > >>
> > >>>
> > >>> Thanks,
> > >>> Amit
> > >>>
> > >>> -----Original Message-----
> > >>> From: Mark Thomas <ma...@apache.org>
> > >>> Sent: Monday, August 28, 2023 11:20 AM
> > >>> To: Tomcat Users List <us...@tomcat.apache.org>
> > >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>
> > >>>
> > >>> CAUTION: This email originated from outside the organization. Do not
> > >> click links or open attachments unless you recognize the sender and know
> > >> the content is safe. If you believe this is a phishing email, use the
> > >> Report to Cybersecurity icon in Outlook.
> > >>>
> > >>>
> > >>>
> > >>> 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> > >>>
> > >>>> Mark,
> > >>>>
> > >>>> Just checking - Did this issue get discussed in any of the core
> > >>>> members' meeting?
> > >>>
> > >>> There are no such meetings. Discussion happens on the mailing lists.
> > >>>
> > >>> Mark
> > >>>
> > >>>
> > >>>>
> > >>>> Thanks,
> > >>>> Amit
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Amit Pande
> > >>>> Sent: Monday, July 31, 2023 9:29 AM
> > >>>> To: Tomcat Users List <us...@tomcat.apache.org>
> > >>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>
> > >>>> Yes, understood.
> > >>>>
> > >>>> Thank you for clarifying. Even I was referring to initial consensus
> > >>>> without any timeline or approach conclusion.
> > >>>>
> > >>>> Thanks,
> > >>>> Amit
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Mark Thomas <ma...@apache.org>
> > >>>> Sent: Friday, July 28, 2023 2:48 PM
> > >>>> To: users@tomcat.apache.org
> > >>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>
> > >>>> On 28/07/2023 19:21, Amit Pande wrote:
> > >>>>> Thank you all for the valuable discussion on this topic.
> > >>>>>
> > >>>>> Is it okay to say that we're agreeing to adding proxy protocol
> > >>>>> support in Tomcat?
> > >>>>
> > >>>> I think that is a little too strong. At this point there is a proposed
> > >>>> approach and no one is objecting but until there is an actual patch to
> > >>>> discuss...
> > >>>>
> > >>>> Keep in mind that any committer can veto a change.
> > >>>>
> > >>>> My sense is that it should be possible to implement this feature while
> > >>>> addressing any concerns that may be raised but it is not guaranteed.
> > >>>>
> > >>>> Mark
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Amit
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> > >>>>> Sent: Thursday, July 27, 2023 4:13 PM
> > >>>>> To: users@tomcat.apache.org
> > >>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>>
> > >>>>> All,
> > >>>>>
> > >>>>> On 7/27/23 12:39, Mark Thomas wrote:
> > >>>>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
> > >>>>>>> On the topic of security, may we consider a trustedProxies setting?
> > >>>>>>
> > >>>>>> Seems reasonable.
> > >>>>>
> > >>>>> We should probably look at what httpd did for all of this.
> > >>>>>
> > >>>>> -chris
> > >>>>>
> > >>>>>>> This
> > >>>>>>> would be an analog to the internalProxies setting on RemoteIpValve.
> > >>>>>>> It would need to be able to function with APR/NIO listening in a
> > >>>>>>> Unix Domain Socket.
> > >>>>>>>
> > >>>>>>> I'm not sure if this is super useful, but the goal would be an
> > >>>>>>> added layer of security to prevent Proxy Protocol header injection.
> > >>>>>>>
> > >>>>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
> > >>>>>>>>> Mark,
> > >>>>>>>>>
> > >>>>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
> > >>>>>>>>>> I'm not a huge fan of this feature in general. I prefer
> > >>>>>>>>>> supporting features backed by specifications rather than vendor
> > >>>>>>>>>> specific hacks.
> > >>>>>>>>>
> > >>>>>>>>> I think the PROXY protocol is fairly standard, even if it's not
> > >>>>>>>>> backed by an RFC. It's published by haproxy, but supported by
> > >>>>>>>>> nginx,
> > >>>>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
> > >>>>>>>> https://ww/
> > >>>>>>>> w.haproxy.com
> > %2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
> > >>>>>>>> s
> > >>>>>>>> -
> > >>>>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com
> > %7C51dbcc5eeac14
> > >>>>>>>> f
> > >>>>>>>> a
> > >>>>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
> > >>>>>>>> 2
> > >>>>>>>> 6
> > >>>>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > >>>>>>>> V
> > >>>>>>>> 2
> > >>>>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
> > >>>>>>>> a
> > >>>>>>>> 0
> > >>>>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
> > >>>>>>>> ).
> > >>>>>>>>
> > >>>>>>>> ACK. That reduces my concerns somewhat.
> > >>>>>>>>
> > >>>>>>>>> Well, the reality is that people want to use this in the real
> > >>>>>>>>> world and this is essentially the only way to do it, barring
> > >>>>>>>>> coming up with a whole new protocol for the purpose (I'm looking
> > >>>>>>>>> at /you/ AJP!).
> > >>>>>>>>
> > >>>>>>>> Indeed.
> > >>>>>>>>
> > >>>>>>>>> So why not use /the/ protocol that (a) exists and (b) is
> > >>>>>>>>> supported by every single product that currently supports this
> > >>>>>>>>> type of thing?
> > >>>>>>>>>
> > >>>>>>>>>> My support for any patch is going to depend on the specifics of
> > >>>>>>>>>> the patch.
> > >>>>>>>>>>
> > >>>>>>>>>> In addition to the comments in the BZ
> > >>>>>>>>>> - exposing the data as a request attribute is inconsistent with
> > >>>>>>>>>> other
> > >>>>>>>>>> mechanisms that solve the same problem (e.g. see
> > >>>>>>>>>> RemoteIpFilter)
> > >>>>>>>>>
> > >>>>>>>>> +1
> > >>>>>>>>>
> > >>>>>>>>> The whole point of PROXY is to kind of mix-together the
> > >>>>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
> > >>>>>>>>> headers for
> > >>>>>>>>> source-information) and the top-level idea of a Connector
> > >>>>>>>>> (something that binds to a socket and pushes bytes around).
> > >>>>>>>>>
> > >>>>>>>>> The confusing thing here is that those two jobs are performed at
> > >>>>>>>>> relatively different levels in Tomcat at the moment, as I
> > >>>>>>>>> understand things.
> > >>>>>>>>
> > >>>>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
> > >>>>>>>> higher level because that is where they sit but the data
> > >>>>>>>> originates from the SocketWrapper.
> > >>>>>>>>
> > >>>>>>>>> If some kind of UberConnector could be built which essentially
> > >>>>>>>>> does something like the following, it would be ideal:
> > >>>>>>>>>
> > >>>>>>>>> public void accept(Socket s) {
> > >>>>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
> > >>>>>>>>>
> > >>>>>>>>> Connector realConnector = getRealConnector();
> > >>>>>>>>>
> > >>>>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> > >>>>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
> > >>>>>>>>>
> > >>>>>>>>> realConnector.takeItAway(s); }
> > >>>>>>>>>
> > >>>>>>>>> I'm sure there are other pieces of information that would be good
> > >>>>>>>>> to pass-through, but the identity of the remote client is the
> > >>>>>>>>> most interesting one.
> > >>>>>>>>
> > >>>>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
> > >>>>>>>> use the SocketWrapper rather than the Connector and to do it in a
> > >>>>>>>> slightly different place. The Acceptor is too early as we want to
> > >>>>>>>> do as little as possible on the Acceptor thread.
> > >>>>>>>>
> > >>>>>>>>>> - needs to be implemented for all Connectors
> > >>>>>>>>>
> > >>>>>>>>> I hope not. The connectors should be able to just have a thin
> > >>>>>>>>> layer in front of them "sipping" the header off the beginning of
> > >>>>>>>>> the connection.
> > >>>>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
> > >>>>>>>>> and so I don't want to appear to be telling you (Mark) "how it
> > >>>>>>>>> works/should work", but conceptually it "seems easy". That may
> > >>>>>>>>> not translate into "easy implementation" or it may mean "tons of
> > >>>>>>>>> refactoring that we wouldn't need if we didn't care that much."
> > >>>>>>>>
> > >>>>>>>> My point was that the provided patch only implements this for NIO.
> > >>>>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
> > >>>>>>>> a lot more difficult to implement and I'd be happy not
> > >>>>>>>> implementing it for APR/Native.
> > >>>>>>>>
> > >>>>>>>>>> - I'd expect it to look more like the SNI processing
> > >>>>>>>>>
> > >>>>>>>>> SNI processing is very connector-dependent, of course, because
> > >>>>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
> > >>>>>>>>> anything.
> > >>>>>>>>> So if it can be implemented as something that can just "sit in
> > >>>>>>>>> front of"
> > >>>>>>>>> *any* connector now or in the future of Tomcat, that would be
> > >>>>>>>>> ideal. It could definitely be implemented as an "optional
> > feature"
> > >>>>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
> > >>>>>>>>> done separately and globally.
> > >>>>>>>>
> > >>>>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
> > >>>>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
> > >>>>>>>>
> > >>>>>>>> SNI is handled independently of implementation and I think PROXY
> > >>>>>>>> should be handled the same way. They also sit at almost the same
> > >>>>>>>> point in the processing (PROXY needs to be first). PROXY parsing
> > >>>>>>>> could be implemented within the existing handshake() method but I
> > >>>>>>>> think it would be much cleaner in a separate method.
> > >>>>>>>>
> > >>>>>>>> Without looking at it too closely I think the implementation would
> > >>>>>>>> look something like:
> > >>>>>>>>
> > >>>>>>>> - a new method on SocketWrapperBase that
> > >>>>>>>> - checks if PROXY is enabled
> > >>>>>>>> - returns immediately if PROXY is not enabled or has
> > already
> > >>>>>>>> been parsed
> > >>>>>>>> - uses a new utility class (or classes) to parse the header
> > >>>>>>>> (reading via the read() methods on SocketWrapperBase)
> > >>>>>>>> - sets the cached values for remoteAddr, remoteHost,
> > >>>>>>>> remotePort etc
> > >>>>>>>> - The SocketProcessor.doRun() implementations add a call to this
> > >>>>>>>> new
> > >>>>>>>> method just before the TLS handshake
> > >>>>>>>>
> > >>>>>>>> If we want to support the TLS information then a little additional
> > >>>>>>>> refactoring will be required (probably to cache the result of
> > >>>>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
> > >>>>>>>> insert a PROXY specific SSLSupport implementation.
> > >>>>>>>>
> > >>>>>>>>> Again, I'm speaking from a position of profound ignorance, here.
> > >>>>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
> > >>>>>>>>> it!"
> > >>>>>>>>> :)
> > >>>>>>>>
> > >>>>>>>> :)
> > >>>>>>>>
> > >>>>>>>> Actually with the patch that has already been provided and the
> > >>>>>>>> suggested implementation outline above I don't think there is too
> > >>>>>>>> much work to do.
> > >>>>>>>>
> > >>>>>>>>>> Generally, I don't think implementing this is going to be
> > >>>>>>>>>> possible as some sort of plug-in.
> > >>>>>>>>>
> > >>>>>>>>> +1 Unless the plug-in is "a whole new set of
> > >>>>>>>>> protocol/endpoint/etc.
> > >>>>>>>>> handlers" which is a rather serious commitment.
> > >>>>>>>>
> > >>>>>>>> On reflection, with the approach above we probably could implement
> > >>>>>>>> this via a new plug-in framework but I am not sure it is worth the
> > >>>>>>>> effort at this point. Something to keep in mind if we have more
> > >>>>>>>> things wanting to integrate at this point in the processing chain.
> > >>>>>>>>
> > >>>>>>>> Mark
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> -chris
> > >>>>>>>>>
> > >>>>>>>>> [1]
> > >>>>>>>>>
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >>>>>>>>> Fhttpd.apache.org
> > >> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
> > >> 40veritas.com
> > %7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0
> > >> search for "haproxy"
> > >>>>>>>>>
> > >>>>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
> > >>>>>>>>>>> Missed to ask this:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Looking the patch, it involves modifying Tomcat code.
> > >>>>>>>>>>> Was wondering if it would be possible to refactor this patch
> > >>>>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
> > >>>>>>>>>>> protocol
> > >>>>>>>> support?
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>> Amit
> > >>>>>>>>>>>
> > >>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>> From: Amit Pande
> > >>>>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
> > >>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> > >>>>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>>>>>>>>
> > >>>>>>>>>>> Chris, Mark,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Any thoughts on this?
> > >>>>>>>>>>>
> > >>>>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
> > >>>>>>>>>>> any concerns (specially security wise)?
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>> Amit
> > >>>>>>>>>>>
> > >>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
> > >>>>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
> > >>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> > >>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>>>>>>>>
> > >>>>>>>>>>> Just a side note, because we're also very interested in this
> > >>>>>>>>>>> patch!
> > >>>>>>>>>>>
> > >>>>>>>>>>> Awhile back, I was successfully able to apply this patch and
> > >>>>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
> > >>>>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
> > >>>>>>>>>>> the relevant/required information to tomcat. I believe we had
> > >>>>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
> > >>>>>>>>>>> patch didn't handle that case.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I can find my notes from that experiment, but I do remember
> > >>>>>>>>>>> getting a significant boost in throughput and decrease in
> > >>>>>>>>>>> latency.
> > >>>>>>>>>>>
> > >>>>>>>>>>> +1 for this patch and willing to help out!
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> > >>>>>>>>>>> <Am...@veritas.com.invalid>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Thank you, Chris, again for inputs.
> > >>>>>>>>>>>> And sorry to circle back on this, late.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> One related question is - does it make sense to use the patch
> > >>>>>>>>>>>> attached in
> > >>>>>>>>>>>>
> > >>
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0
> > >> ?
> > >>>>>>>>>>>> And potentially, get it integrated into Tomcat versions?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> There are concerns from Mark about using the patch in its
> > >>>>>>>>>>>> current state, but I see last comment (#24) on the issue and
> > >>>>>>>>>>>> looks like there are some more points to be concluded.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>> Amit
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> > >>>>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
> > >>>>>>>>>>>> To: users@tomcat.apache.org
> > >>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
> > >>>>>>>>>>>> Tomcat
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Amit,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
> > >>>>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
> > >>>>>>>>>>>>> TCP proxy e.g.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> https://www/.
> > >>>>>>>>>>>> envoyproxy.io
> > >>>>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> > >>>>>>>>>>>>
> > features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
> > >>>>>>>>>>>> c
> > >>>>>>>>>>>> om
> > >>>>>>>> %7Ca
> > >>>>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
> > >>>>>>>>>>>> a
> > >>>>>>>>>>>> c
> > >>>>>>>>>>>> 32%7C0
> > >>>>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > >>>>>>>>>>>> L
> > >>>>>>>>>>>> j
> > >>>>>>>>>>>> AwMDAi
> > >>>>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> > >>>>>>>>>>>> &
> > >>>>>>>>>>>> s
> > >>>>>>>>>>>> data=W
> > >>>>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> > >>>>>>>>>>>> which supports the proxy protocol.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Since there is not much action on this
> > >>>>>>>>>>>>
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
> > >>>>>>>>>>>> F
> > >>>>>>>>>>>> %25
> > >>>>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com
> > %7C51dbcc5eea
> > >>>>>>>>>>>> c
> > >>>>>>>>>>>> 1
> > >>>>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
> > >>>>>>>>>>>> 0
> > >>>>>>>>>>>> %
> > >>>>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > >>>>>>>>>>>> D
> > >>>>>>>>>>>> A
> > >>>>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > >>>>>>>>>>>> C
> > >>>>>>>>>>>> &
> > >>>>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
> > >>>>>>>>>>>> 0
> > >>>>>>>>>>>> pache.org
> > >>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
> > >>>>>>>> 40veritas.com
> > %7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
> > >>>>>>>> 5
> > >>>>>>>> b
> > >>>>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
> > >>>>>>>> 3
> > >>>>>>>> d
> > >>>>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > >>>>>>>> D
> > >>>>>>>> %
> > >>>>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
> > >>>>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
> > >>>>>>>> is running behind HTTP proxies and not TCP proxies?
> > >>>>>>>>>>>>> Or does it mean that, Tomcat or applications running in
> > >>>>>>>>>>>>> Tomcat does not
> > >>>>>>>>>>>> need the remote client address information?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
> > >>>>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
> > >>>>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
> > >>>>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
> > >>>>>>>>>>>> multiple services behind my reverse-proxy which run in
> > >>>>>>>>>>>> different places. It's not just s dumb pass-through.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hope that helps,
> > >>>>>>>>>>>> -chris
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> > >>>>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
> > >>>>>>>>>>>>> To: users@tomcat.apache.org
> > >>>>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Amit,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
> > >>>>>>>>>>>>>> We have a similar requirement as mentioned in the below
> > >>>>>>>>>>>>>> enhancement
> > >>>>>>>>>>>> request.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> https://bz/.
> > >>>>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com
> > %7C07ebe3c927ed4
> > >>>>>>>>>>>>>> b
> > >>>>>>>>>>>>>> 7
> > >>>>>>>>>>>>>> 87206
> > >>>>>>>>>>>>>> 08
> > >>>>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
> > >>>>>>>>>>>>>> 9
> > >>>>>>>>>>>>>> 3
> > >>>>>>>>>>>>>> 50613
> > >>>>>>>>>>>>>> 56
> > >>>>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> > >>>>>>>>>>>>>> l
> > >>>>>>>>>>>>>> u
> > >>>>>>>>>>>>>> MzIiL
> > >>>>>>>>>>>>>> CJ
> > >>>>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
> > >>>>>>>>>>>>>> t
> > >>>>>>>>>>>>>> L
> > >>>>>>>>>>>>>> qUzY9
> > >>>>>>>>>>>>>> JM
> > >>>>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> > >>>>>>>>>>>>>> pache.org
> > >>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> > >>>>>>>>>>>>>> P
> > >>>>>>>>>>>>>> ande%40veritas.com
> > %7Cab789327b86845e8ad7208db50046f55%7Cfc8e
> > >>>>>>>>>>>>>> 1
> > >>>>>>>>>>>>>> 3
> > >>>>>>>>>>>>>> c0422
> > >>>>>>>>>>>>>> c4
> > >>>>>>>>>>>>>> c
> > >>>>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
> > >>>>>>>>>>>>>> T
> > >>>>>>>>>>>>>> W
> > >>>>>>>>>>>>>> FpbGZ
> > >>>>>>>>>>>>>> sb
> > >>>>>>>>>>>>>> 3
> > >>>>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> > >>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>> 6
> > >>>>>>>>>>>>>> Mn0%3
> > >>>>>>>>>>>>>> D%
> > >>>>>>>>>>>>>> 7
> > >>>>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
> > >>>>>>>>>>>>>> l
> > >>>>>>>>>>>>>> 4
> > >>>>>>>>>>>>>> mY%3D
> > >>>>>>>>>>>>>> &r
> > >>>>>>>>>>>>>> e
> > >>>>>>>>>>>>>> served=0
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
> > >>>>>>>>>>>>>> releases?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Nothing at the moment that I know of.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I thought that markt had looked at this a while back and said
> > >>>>>>>>>>>>> it didn't
> > >>>>>>>>>>>> look too difficult. It does require Tomcat to handle the
> > >>>>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
> > >>>>>>>>>>>> thought that had been done at some point, but it may not have.
> > >>>>>>>>>>>> Handling the stream directly may have some other advantages as
> > >>>>>>>>>>>> well, though it definitely makes the code more complicated.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Also, since this was requested long time back and there is
> > >>>>>>>>>>>>>> no update, are there any other alternatives to pass the
> > >>>>>>>>>>>>>> client information from load balancer to Tomcat in
> > >>>>>>>>>>>>>> situations where there is no SSL termination at load
> > balancer?
> > >>>>>>>>>>>>> You mean like a network load balancer where the lb is just
> > >>>>>>>>>>>>> proxying
> > >>>>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
> > >>>>>>>>>>>> really is the best way to do that, honestly.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -chris
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -------------------------------------------------------------
> > >>>>>>>>>>>>> -
> > >>>>>>>>>>>>> -
> > >>>>>>>>>>>>> -----
> > >>>>>>>>>>>>> - To unsubscribe, e-mail:
> > users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>>>>> For additional commands, e-mail:
> > users-help@tomcat.apache.org
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -------------------------------------------------------------
> > >>>>>>>>>>>>> -
> > >>>>>>>>>>>>> -
> > >>>>>>>>>>>>> -----
> > >>>>>>>>>>>>> - To unsubscribe, e-mail:
> > users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>>>>> For additional commands, e-mail:
> > users-help@tomcat.apache.org
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --------------------------------------------------------------
> > >>>>>>>>>>>> -
> > >>>>>>>>>>>> -
> > >>>>>>>>>>>> ----- To unsubscribe, e-mail:
> > >>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --------------------------------------------------------------
> > >>>>>>>>>>>> -
> > >>>>>>>>>>>> -
> > >>>>>>>>>>>> ----- To unsubscribe, e-mail:
> > >>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Jonathan | exabrial@gmail.com
> > >>>>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
> > >>>>>>>>>>> see it as half full.
> > >>>>>>>>>>> Engineers, of course, understand the glass is twice as big as
> > >>>>>>>>>>> it needs to be.
> > >>>>>>>>>>>
> > >>>>>>>>>>> ---------------------------------------------------------------
> > >>>>>>>>>>> -
> > >>>>>>>>>>> -
> > >>>>>>>>>>> ---- To unsubscribe, e-mail:
> > >>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> ----------------------------------------------------------------
> > >>>>>>>>>> -
> > >>>>>>>>>> -
> > >>>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> -----------------------------------------------------------------
> > >>>>>>>>> -
> > >>>>>>>>> -
> > >>>>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ------------------------------------------------------------------
> > >>>>>>>> -
> > >>>>>>>> -
> > >>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> --------------------------------------------------------------------
> > >>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as
half full.
Engineers, of course, understand the glass is twice as big as it needs to be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Adwait Kumar Singh <ad...@gmail.com>.
Hey,
Checking in on this thread. Is someone actively working on this?
I am more than happy to contribute/help in any way to move this forward
quickly.
Thanks,
Adwait.
On Tue, Sep 5, 2023 at 1:11 PM Mark Thomas <ma...@apache.org> wrote:
> On 04/09/2023 15:41, Jonathan S. Fisher wrote:
> > Mark thank you again for your leadership and setting expectations. I'm
> > going to commit to working on this with anyone else that wants to help
> with
> > the goal of a patch by year end. I want to nail the patch with minimal
> > rework that meets Tomcat project quality standards. To that end, I'll
> > attempt to summarize what you expect here and if you could comment and
> > correct my understanding that would be appreciated.
> >
> > It sounds like you're satisfied with the ubiquity of the Proxy protocol
> and
> > that it has an RFC
> > We'll target just implementing the latest version of the Proxy protocol
> > We'll implement a "TrustedProxies" feature similar to what the Remote IP
> > Valve does
> > We'll implement a, or modify the RemoteIp, valve to be able to set the
> > remote IP from Proxy protocol headers
> > We'll follow the RFC spec and reject any request that does a proper Proxy
> > protocol header
> > I'm particularly interested in the Proxy protocol over Unix Domain
> Sockets,
> > so expect to see a lot of the work focused on this, but accepting Proxy
> > Protocol over TCP looks to be quite important from the comments on this
> > email chain
> >
> > If I may ask two things:
> > Can you summarize your desired implementation? What point in the stack
> > should we target to implement this?
>
> See my response earlier in this thread that suggested it sits alongside
> SNI processing. I still think that makes sense. If during implementation
> you reach a different conclusion then make the case for the alternative
> approach on list.
>
> > One thing I'm not familiar with on Tomcat is the testing expectations. If
> > you can point to a set of unit tests and a set of integration tests and
> say
> > "Do it like this"
>
> Something like (only a guide)
>
>
> https://github.com/apache/tomcat/blob/main/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
>
> to test the implementation directly and probably something based on
> SimpleHttpClient see
>
>
> https://github.com/apache/tomcat/blob/main/test/org/apache/coyote/http11/TestHttp11Processor.java
>
> for various examples. The main thing is I suspect you'll need control of
> the individual bytes and SimpleHttpClient provides a reasonably simple
> basis for that.
>
> What we often do when we want to test things like setting remote IP
> addresses etc. is echo the value in the response body and then check
> that value in the client.
>
> > Anything else on the original patch you liked/didn't like? (
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
>
> It helps if you enable Checkstyle for your local build. It helps keep
> things in roughly the same coding style (we are slowly tightening up on
> that). Ideally, use the clean-up and formatting configurations we have
> for Eclipse in res/ide-support/eclipse .
>
> This is sufficiently complex that I am expecting several iterations to
> be required. if it is simpler for you to manage with a PR then that is
> fine and probably easier to work with than a patch in Bugzilla.
>
> Mark
>
> >
> > Thank you,
> >
> >
> > On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 28/08/2023 18:44, Amit Pande wrote:
> >>> Oh, sure. So, what would be the best way to get some conclusion on this
> >> thread?
> >>
> >> Provide a patch for review based on the feedback provided here and in
> >> the BZ issue.
> >>
> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
> >> ticket isn't updated for long. Perhaps add comments/ask the folks on
> user
> >> list to vote?
> >>
> >> That is more likely to irritate folks rather than encourage them to help
> >> you progress your patch.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -----Original Message-----
> >>> From: Mark Thomas <ma...@apache.org>
> >>> Sent: Monday, August 28, 2023 11:20 AM
> >>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>>
> >>> CAUTION: This email originated from outside the organization. Do not
> >> click links or open attachments unless you recognize the sender and know
> >> the content is safe. If you believe this is a phishing email, use the
> >> Report to Cybersecurity icon in Outlook.
> >>>
> >>>
> >>>
> >>> 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> >>>
> >>>> Mark,
> >>>>
> >>>> Just checking - Did this issue get discussed in any of the core
> >>>> members' meeting?
> >>>
> >>> There are no such meetings. Discussion happens on the mailing lists.
> >>>
> >>> Mark
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>> Amit
> >>>>
> >>>> -----Original Message-----
> >>>> From: Amit Pande
> >>>> Sent: Monday, July 31, 2023 9:29 AM
> >>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>
> >>>> Yes, understood.
> >>>>
> >>>> Thank you for clarifying. Even I was referring to initial consensus
> >>>> without any timeline or approach conclusion.
> >>>>
> >>>> Thanks,
> >>>> Amit
> >>>>
> >>>> -----Original Message-----
> >>>> From: Mark Thomas <ma...@apache.org>
> >>>> Sent: Friday, July 28, 2023 2:48 PM
> >>>> To: users@tomcat.apache.org
> >>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>
> >>>> On 28/07/2023 19:21, Amit Pande wrote:
> >>>>> Thank you all for the valuable discussion on this topic.
> >>>>>
> >>>>> Is it okay to say that we're agreeing to adding proxy protocol
> >>>>> support in Tomcat?
> >>>>
> >>>> I think that is a little too strong. At this point there is a proposed
> >>>> approach and no one is objecting but until there is an actual patch to
> >>>> discuss...
> >>>>
> >>>> Keep in mind that any committer can veto a change.
> >>>>
> >>>> My sense is that it should be possible to implement this feature while
> >>>> addressing any concerns that may be raised but it is not guaranteed.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Amit
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>> Sent: Thursday, July 27, 2023 4:13 PM
> >>>>> To: users@tomcat.apache.org
> >>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>
> >>>>> All,
> >>>>>
> >>>>> On 7/27/23 12:39, Mark Thomas wrote:
> >>>>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
> >>>>>>> On the topic of security, may we consider a trustedProxies setting?
> >>>>>>
> >>>>>> Seems reasonable.
> >>>>>
> >>>>> We should probably look at what httpd did for all of this.
> >>>>>
> >>>>> -chris
> >>>>>
> >>>>>>> This
> >>>>>>> would be an analog to the internalProxies setting on RemoteIpValve.
> >>>>>>> It would need to be able to function with APR/NIO listening in a
> >>>>>>> Unix Domain Socket.
> >>>>>>>
> >>>>>>> I'm not sure if this is super useful, but the goal would be an
> >>>>>>> added layer of security to prevent Proxy Protocol header injection.
> >>>>>>>
> >>>>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
> >>>>>>>>> Mark,
> >>>>>>>>>
> >>>>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
> >>>>>>>>>> I'm not a huge fan of this feature in general. I prefer
> >>>>>>>>>> supporting features backed by specifications rather than vendor
> >>>>>>>>>> specific hacks.
> >>>>>>>>>
> >>>>>>>>> I think the PROXY protocol is fairly standard, even if it's not
> >>>>>>>>> backed by an RFC. It's published by haproxy, but supported by
> >>>>>>>>> nginx,
> >>>>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
> >>>>>>>> https://ww/
> >>>>>>>> w.haproxy.com
> %2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
> >>>>>>>> s
> >>>>>>>> -
> >>>>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com
> %7C51dbcc5eeac14
> >>>>>>>> f
> >>>>>>>> a
> >>>>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
> >>>>>>>> 2
> >>>>>>>> 6
> >>>>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> >>>>>>>> V
> >>>>>>>> 2
> >>>>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
> >>>>>>>> a
> >>>>>>>> 0
> >>>>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
> >>>>>>>> ).
> >>>>>>>>
> >>>>>>>> ACK. That reduces my concerns somewhat.
> >>>>>>>>
> >>>>>>>>> Well, the reality is that people want to use this in the real
> >>>>>>>>> world and this is essentially the only way to do it, barring
> >>>>>>>>> coming up with a whole new protocol for the purpose (I'm looking
> >>>>>>>>> at /you/ AJP!).
> >>>>>>>>
> >>>>>>>> Indeed.
> >>>>>>>>
> >>>>>>>>> So why not use /the/ protocol that (a) exists and (b) is
> >>>>>>>>> supported by every single product that currently supports this
> >>>>>>>>> type of thing?
> >>>>>>>>>
> >>>>>>>>>> My support for any patch is going to depend on the specifics of
> >>>>>>>>>> the patch.
> >>>>>>>>>>
> >>>>>>>>>> In addition to the comments in the BZ
> >>>>>>>>>> - exposing the data as a request attribute is inconsistent with
> >>>>>>>>>> other
> >>>>>>>>>> mechanisms that solve the same problem (e.g. see
> >>>>>>>>>> RemoteIpFilter)
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> The whole point of PROXY is to kind of mix-together the
> >>>>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
> >>>>>>>>> headers for
> >>>>>>>>> source-information) and the top-level idea of a Connector
> >>>>>>>>> (something that binds to a socket and pushes bytes around).
> >>>>>>>>>
> >>>>>>>>> The confusing thing here is that those two jobs are performed at
> >>>>>>>>> relatively different levels in Tomcat at the moment, as I
> >>>>>>>>> understand things.
> >>>>>>>>
> >>>>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
> >>>>>>>> higher level because that is where they sit but the data
> >>>>>>>> originates from the SocketWrapper.
> >>>>>>>>
> >>>>>>>>> If some kind of UberConnector could be built which essentially
> >>>>>>>>> does something like the following, it would be ideal:
> >>>>>>>>>
> >>>>>>>>> public void accept(Socket s) {
> >>>>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
> >>>>>>>>>
> >>>>>>>>> Connector realConnector = getRealConnector();
> >>>>>>>>>
> >>>>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> >>>>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
> >>>>>>>>>
> >>>>>>>>> realConnector.takeItAway(s); }
> >>>>>>>>>
> >>>>>>>>> I'm sure there are other pieces of information that would be good
> >>>>>>>>> to pass-through, but the identity of the remote client is the
> >>>>>>>>> most interesting one.
> >>>>>>>>
> >>>>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
> >>>>>>>> use the SocketWrapper rather than the Connector and to do it in a
> >>>>>>>> slightly different place. The Acceptor is too early as we want to
> >>>>>>>> do as little as possible on the Acceptor thread.
> >>>>>>>>
> >>>>>>>>>> - needs to be implemented for all Connectors
> >>>>>>>>>
> >>>>>>>>> I hope not. The connectors should be able to just have a thin
> >>>>>>>>> layer in front of them "sipping" the header off the beginning of
> >>>>>>>>> the connection.
> >>>>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
> >>>>>>>>> and so I don't want to appear to be telling you (Mark) "how it
> >>>>>>>>> works/should work", but conceptually it "seems easy". That may
> >>>>>>>>> not translate into "easy implementation" or it may mean "tons of
> >>>>>>>>> refactoring that we wouldn't need if we didn't care that much."
> >>>>>>>>
> >>>>>>>> My point was that the provided patch only implements this for NIO.
> >>>>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
> >>>>>>>> a lot more difficult to implement and I'd be happy not
> >>>>>>>> implementing it for APR/Native.
> >>>>>>>>
> >>>>>>>>>> - I'd expect it to look more like the SNI processing
> >>>>>>>>>
> >>>>>>>>> SNI processing is very connector-dependent, of course, because
> >>>>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
> >>>>>>>>> anything.
> >>>>>>>>> So if it can be implemented as something that can just "sit in
> >>>>>>>>> front of"
> >>>>>>>>> *any* connector now or in the future of Tomcat, that would be
> >>>>>>>>> ideal. It could definitely be implemented as an "optional
> feature"
> >>>>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
> >>>>>>>>> done separately and globally.
> >>>>>>>>
> >>>>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
> >>>>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
> >>>>>>>>
> >>>>>>>> SNI is handled independently of implementation and I think PROXY
> >>>>>>>> should be handled the same way. They also sit at almost the same
> >>>>>>>> point in the processing (PROXY needs to be first). PROXY parsing
> >>>>>>>> could be implemented within the existing handshake() method but I
> >>>>>>>> think it would be much cleaner in a separate method.
> >>>>>>>>
> >>>>>>>> Without looking at it too closely I think the implementation would
> >>>>>>>> look something like:
> >>>>>>>>
> >>>>>>>> - a new method on SocketWrapperBase that
> >>>>>>>> - checks if PROXY is enabled
> >>>>>>>> - returns immediately if PROXY is not enabled or has
> already
> >>>>>>>> been parsed
> >>>>>>>> - uses a new utility class (or classes) to parse the header
> >>>>>>>> (reading via the read() methods on SocketWrapperBase)
> >>>>>>>> - sets the cached values for remoteAddr, remoteHost,
> >>>>>>>> remotePort etc
> >>>>>>>> - The SocketProcessor.doRun() implementations add a call to this
> >>>>>>>> new
> >>>>>>>> method just before the TLS handshake
> >>>>>>>>
> >>>>>>>> If we want to support the TLS information then a little additional
> >>>>>>>> refactoring will be required (probably to cache the result of
> >>>>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
> >>>>>>>> insert a PROXY specific SSLSupport implementation.
> >>>>>>>>
> >>>>>>>>> Again, I'm speaking from a position of profound ignorance, here.
> >>>>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
> >>>>>>>>> it!"
> >>>>>>>>> :)
> >>>>>>>>
> >>>>>>>> :)
> >>>>>>>>
> >>>>>>>> Actually with the patch that has already been provided and the
> >>>>>>>> suggested implementation outline above I don't think there is too
> >>>>>>>> much work to do.
> >>>>>>>>
> >>>>>>>>>> Generally, I don't think implementing this is going to be
> >>>>>>>>>> possible as some sort of plug-in.
> >>>>>>>>>
> >>>>>>>>> +1 Unless the plug-in is "a whole new set of
> >>>>>>>>> protocol/endpoint/etc.
> >>>>>>>>> handlers" which is a rather serious commitment.
> >>>>>>>>
> >>>>>>>> On reflection, with the approach above we probably could implement
> >>>>>>>> this via a new plug-in framework but I am not sure it is worth the
> >>>>>>>> effort at this point. Something to keep in mind if we have more
> >>>>>>>> things wanting to integrate at this point in the processing chain.
> >>>>>>>>
> >>>>>>>> Mark
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -chris
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>>>> Fhttpd.apache.org
> >> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
> >> 40veritas.com
> %7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0
> >> search for "haproxy"
> >>>>>>>>>
> >>>>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
> >>>>>>>>>>> Missed to ask this:
> >>>>>>>>>>>
> >>>>>>>>>>> Looking the patch, it involves modifying Tomcat code.
> >>>>>>>>>>> Was wondering if it would be possible to refactor this patch
> >>>>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
> >>>>>>>>>>> protocol
> >>>>>>>> support?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Amit
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Amit Pande
> >>>>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
> >>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>>>
> >>>>>>>>>>> Chris, Mark,
> >>>>>>>>>>>
> >>>>>>>>>>> Any thoughts on this?
> >>>>>>>>>>>
> >>>>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
> >>>>>>>>>>> any concerns (specially security wise)?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Amit
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
> >>>>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
> >>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>>>
> >>>>>>>>>>> Just a side note, because we're also very interested in this
> >>>>>>>>>>> patch!
> >>>>>>>>>>>
> >>>>>>>>>>> Awhile back, I was successfully able to apply this patch and
> >>>>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
> >>>>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
> >>>>>>>>>>> the relevant/required information to tomcat. I believe we had
> >>>>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
> >>>>>>>>>>> patch didn't handle that case.
> >>>>>>>>>>>
> >>>>>>>>>>> I can find my notes from that experiment, but I do remember
> >>>>>>>>>>> getting a significant boost in throughput and decrease in
> >>>>>>>>>>> latency.
> >>>>>>>>>>>
> >>>>>>>>>>> +1 for this patch and willing to help out!
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> >>>>>>>>>>> <Am...@veritas.com.invalid>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Thank you, Chris, again for inputs.
> >>>>>>>>>>>> And sorry to circle back on this, late.
> >>>>>>>>>>>>
> >>>>>>>>>>>> One related question is - does it make sense to use the patch
> >>>>>>>>>>>> attached in
> >>>>>>>>>>>>
> >>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0
> >> ?
> >>>>>>>>>>>> And potentially, get it integrated into Tomcat versions?
> >>>>>>>>>>>>
> >>>>>>>>>>>> There are concerns from Mark about using the patch in its
> >>>>>>>>>>>> current state, but I see last comment (#24) on the issue and
> >>>>>>>>>>>> looks like there are some more points to be concluded.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Amit
> >>>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
> >>>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>>>>> Tomcat
> >>>>>>>>>>>>
> >>>>>>>>>>>> Amit,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
> >>>>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
> >>>>>>>>>>>>> TCP proxy e.g.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> https://www/.
> >>>>>>>>>>>> envoyproxy.io
> >>>>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> >>>>>>>>>>>>
> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
> >>>>>>>>>>>> c
> >>>>>>>>>>>> om
> >>>>>>>> %7Ca
> >>>>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
> >>>>>>>>>>>> a
> >>>>>>>>>>>> c
> >>>>>>>>>>>> 32%7C0
> >>>>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> >>>>>>>>>>>> L
> >>>>>>>>>>>> j
> >>>>>>>>>>>> AwMDAi
> >>>>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >>>>>>>>>>>> &
> >>>>>>>>>>>> s
> >>>>>>>>>>>> data=W
> >>>>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> >>>>>>>>>>>> which supports the proxy protocol.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Since there is not much action on this
> >>>>>>>>>>>>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
> >>>>>>>>>>>> F
> >>>>>>>>>>>> %25
> >>>>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com
> %7C51dbcc5eea
> >>>>>>>>>>>> c
> >>>>>>>>>>>> 1
> >>>>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
> >>>>>>>>>>>> 0
> >>>>>>>>>>>> %
> >>>>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>>>>>>>>>> D
> >>>>>>>>>>>> A
> >>>>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >>>>>>>>>>>> C
> >>>>>>>>>>>> &
> >>>>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
> >>>>>>>>>>>> 0
> >>>>>>>>>>>> pache.org
> >>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
> >>>>>>>> 40veritas.com
> %7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
> >>>>>>>> 5
> >>>>>>>> b
> >>>>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
> >>>>>>>> 3
> >>>>>>>> d
> >>>>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>>>> D
> >>>>>>>> %
> >>>>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
> >>>>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
> >>>>>>>> is running behind HTTP proxies and not TCP proxies?
> >>>>>>>>>>>>> Or does it mean that, Tomcat or applications running in
> >>>>>>>>>>>>> Tomcat does not
> >>>>>>>>>>>> need the remote client address information?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
> >>>>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
> >>>>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
> >>>>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
> >>>>>>>>>>>> multiple services behind my reverse-proxy which run in
> >>>>>>>>>>>> different places. It's not just s dumb pass-through.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hope that helps,
> >>>>>>>>>>>> -chris
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
> >>>>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Amit,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
> >>>>>>>>>>>>>> We have a similar requirement as mentioned in the below
> >>>>>>>>>>>>>> enhancement
> >>>>>>>>>>>> request.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://bz/.
> >>>>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com
> %7C07ebe3c927ed4
> >>>>>>>>>>>>>> b
> >>>>>>>>>>>>>> 7
> >>>>>>>>>>>>>> 87206
> >>>>>>>>>>>>>> 08
> >>>>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
> >>>>>>>>>>>>>> 9
> >>>>>>>>>>>>>> 3
> >>>>>>>>>>>>>> 50613
> >>>>>>>>>>>>>> 56
> >>>>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> >>>>>>>>>>>>>> l
> >>>>>>>>>>>>>> u
> >>>>>>>>>>>>>> MzIiL
> >>>>>>>>>>>>>> CJ
> >>>>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
> >>>>>>>>>>>>>> t
> >>>>>>>>>>>>>> L
> >>>>>>>>>>>>>> qUzY9
> >>>>>>>>>>>>>> JM
> >>>>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >>>>>>>>>>>>>> pache.org
> >>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >>>>>>>>>>>>>> P
> >>>>>>>>>>>>>> ande%40veritas.com
> %7Cab789327b86845e8ad7208db50046f55%7Cfc8e
> >>>>>>>>>>>>>> 1
> >>>>>>>>>>>>>> 3
> >>>>>>>>>>>>>> c0422
> >>>>>>>>>>>>>> c4
> >>>>>>>>>>>>>> c
> >>>>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
> >>>>>>>>>>>>>> T
> >>>>>>>>>>>>>> W
> >>>>>>>>>>>>>> FpbGZ
> >>>>>>>>>>>>>> sb
> >>>>>>>>>>>>>> 3
> >>>>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>> 6
> >>>>>>>>>>>>>> Mn0%3
> >>>>>>>>>>>>>> D%
> >>>>>>>>>>>>>> 7
> >>>>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
> >>>>>>>>>>>>>> l
> >>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>> mY%3D
> >>>>>>>>>>>>>> &r
> >>>>>>>>>>>>>> e
> >>>>>>>>>>>>>> served=0
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
> >>>>>>>>>>>>>> releases?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nothing at the moment that I know of.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I thought that markt had looked at this a while back and said
> >>>>>>>>>>>>> it didn't
> >>>>>>>>>>>> look too difficult. It does require Tomcat to handle the
> >>>>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
> >>>>>>>>>>>> thought that had been done at some point, but it may not have.
> >>>>>>>>>>>> Handling the stream directly may have some other advantages as
> >>>>>>>>>>>> well, though it definitely makes the code more complicated.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Also, since this was requested long time back and there is
> >>>>>>>>>>>>>> no update, are there any other alternatives to pass the
> >>>>>>>>>>>>>> client information from load balancer to Tomcat in
> >>>>>>>>>>>>>> situations where there is no SSL termination at load
> balancer?
> >>>>>>>>>>>>> You mean like a network load balancer where the lb is just
> >>>>>>>>>>>>> proxying
> >>>>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
> >>>>>>>>>>>> really is the best way to do that, honestly.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -chris
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -------------------------------------------------------------
> >>>>>>>>>>>>> -
> >>>>>>>>>>>>> -
> >>>>>>>>>>>>> -----
> >>>>>>>>>>>>> - To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail:
> users-help@tomcat.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -------------------------------------------------------------
> >>>>>>>>>>>>> -
> >>>>>>>>>>>>> -
> >>>>>>>>>>>>> -----
> >>>>>>>>>>>>> - To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail:
> users-help@tomcat.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --------------------------------------------------------------
> >>>>>>>>>>>> -
> >>>>>>>>>>>> -
> >>>>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --------------------------------------------------------------
> >>>>>>>>>>>> -
> >>>>>>>>>>>> -
> >>>>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Jonathan | exabrial@gmail.com
> >>>>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
> >>>>>>>>>>> see it as half full.
> >>>>>>>>>>> Engineers, of course, understand the glass is twice as big as
> >>>>>>>>>>> it needs to be.
> >>>>>>>>>>>
> >>>>>>>>>>> ---------------------------------------------------------------
> >>>>>>>>>>> -
> >>>>>>>>>>> -
> >>>>>>>>>>> ---- To unsubscribe, e-mail:
> >>>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----------------------------------------------------------------
> >>>>>>>>>> -
> >>>>>>>>>> -
> >>>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----------------------------------------------------------------
> >>>>>>>>> -
> >>>>>>>>> -
> >>>>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> ------------------------------------------------------------------
> >>>>>>>> -
> >>>>>>>> -
> >>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --------------------------------------------------------------------
> >>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 04/09/2023 15:41, Jonathan S. Fisher wrote:
> Mark thank you again for your leadership and setting expectations. I'm
> going to commit to working on this with anyone else that wants to help with
> the goal of a patch by year end. I want to nail the patch with minimal
> rework that meets Tomcat project quality standards. To that end, I'll
> attempt to summarize what you expect here and if you could comment and
> correct my understanding that would be appreciated.
>
> It sounds like you're satisfied with the ubiquity of the Proxy protocol and
> that it has an RFC
> We'll target just implementing the latest version of the Proxy protocol
> We'll implement a "TrustedProxies" feature similar to what the Remote IP
> Valve does
> We'll implement a, or modify the RemoteIp, valve to be able to set the
> remote IP from Proxy protocol headers
> We'll follow the RFC spec and reject any request that does a proper Proxy
> protocol header
> I'm particularly interested in the Proxy protocol over Unix Domain Sockets,
> so expect to see a lot of the work focused on this, but accepting Proxy
> Protocol over TCP looks to be quite important from the comments on this
> email chain
>
> If I may ask two things:
> Can you summarize your desired implementation? What point in the stack
> should we target to implement this?
See my response earlier in this thread that suggested it sits alongside
SNI processing. I still think that makes sense. If during implementation
you reach a different conclusion then make the case for the alternative
approach on list.
> One thing I'm not familiar with on Tomcat is the testing expectations. If
> you can point to a set of unit tests and a set of integration tests and say
> "Do it like this"
Something like (only a guide)
https://github.com/apache/tomcat/blob/main/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
to test the implementation directly and probably something based on
SimpleHttpClient see
https://github.com/apache/tomcat/blob/main/test/org/apache/coyote/http11/TestHttp11Processor.java
for various examples. The main thing is I suspect you'll need control of
the individual bytes and SimpleHttpClient provides a reasonably simple
basis for that.
What we often do when we want to test things like setting remote IP
addresses etc. is echo the value in the response body and then check
that value in the client.
> Anything else on the original patch you liked/didn't like? (
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
It helps if you enable Checkstyle for your local build. It helps keep
things in roughly the same coding style (we are slowly tightening up on
that). Ideally, use the clean-up and formatting configurations we have
for Eclipse in res/ide-support/eclipse .
This is sufficiently complex that I am expecting several iterations to
be required. if it is simpler for you to manage with a PR then that is
fine and probably easier to work with than a patch in Bugzilla.
Mark
>
> Thank you,
>
>
> On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 28/08/2023 18:44, Amit Pande wrote:
>>> Oh, sure. So, what would be the best way to get some conclusion on this
>> thread?
>>
>> Provide a patch for review based on the feedback provided here and in
>> the BZ issue.
>>
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
>> ticket isn't updated for long. Perhaps add comments/ask the folks on user
>> list to vote?
>>
>> That is more likely to irritate folks rather than encourage them to help
>> you progress your patch.
>>
>> Mark
>>
>>
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Mark Thomas <ma...@apache.org>
>>> Sent: Monday, August 28, 2023 11:20 AM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>>
>>> CAUTION: This email originated from outside the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe. If you believe this is a phishing email, use the
>> Report to Cybersecurity icon in Outlook.
>>>
>>>
>>>
>>> 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
>>>
>>>> Mark,
>>>>
>>>> Just checking - Did this issue get discussed in any of the core
>>>> members' meeting?
>>>
>>> There are no such meetings. Discussion happens on the mailing lists.
>>>
>>> Mark
>>>
>>>
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>> -----Original Message-----
>>>> From: Amit Pande
>>>> Sent: Monday, July 31, 2023 9:29 AM
>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> Yes, understood.
>>>>
>>>> Thank you for clarifying. Even I was referring to initial consensus
>>>> without any timeline or approach conclusion.
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>> -----Original Message-----
>>>> From: Mark Thomas <ma...@apache.org>
>>>> Sent: Friday, July 28, 2023 2:48 PM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> On 28/07/2023 19:21, Amit Pande wrote:
>>>>> Thank you all for the valuable discussion on this topic.
>>>>>
>>>>> Is it okay to say that we're agreeing to adding proxy protocol
>>>>> support in Tomcat?
>>>>
>>>> I think that is a little too strong. At this point there is a proposed
>>>> approach and no one is objecting but until there is an actual patch to
>>>> discuss...
>>>>
>>>> Keep in mind that any committer can veto a change.
>>>>
>>>> My sense is that it should be possible to implement this feature while
>>>> addressing any concerns that may be raised but it is not guaranteed.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Amit
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>> Sent: Thursday, July 27, 2023 4:13 PM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>
>>>>> All,
>>>>>
>>>>> On 7/27/23 12:39, Mark Thomas wrote:
>>>>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>>>>>> On the topic of security, may we consider a trustedProxies setting?
>>>>>>
>>>>>> Seems reasonable.
>>>>>
>>>>> We should probably look at what httpd did for all of this.
>>>>>
>>>>> -chris
>>>>>
>>>>>>> This
>>>>>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>>>>>> It would need to be able to function with APR/NIO listening in a
>>>>>>> Unix Domain Socket.
>>>>>>>
>>>>>>> I'm not sure if this is super useful, but the goal would be an
>>>>>>> added layer of security to prevent Proxy Protocol header injection.
>>>>>>>
>>>>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>>>>>> Mark,
>>>>>>>>>
>>>>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>>>>>> supporting features backed by specifications rather than vendor
>>>>>>>>>> specific hacks.
>>>>>>>>>
>>>>>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>>>>>> nginx,
>>>>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>>>>>> https://ww/
>>>>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
>>>>>>>> s
>>>>>>>> -
>>>>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
>>>>>>>> f
>>>>>>>> a
>>>>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
>>>>>>>> 2
>>>>>>>> 6
>>>>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>>>>>> V
>>>>>>>> 2
>>>>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
>>>>>>>> a
>>>>>>>> 0
>>>>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>>>>>> ).
>>>>>>>>
>>>>>>>> ACK. That reduces my concerns somewhat.
>>>>>>>>
>>>>>>>>> Well, the reality is that people want to use this in the real
>>>>>>>>> world and this is essentially the only way to do it, barring
>>>>>>>>> coming up with a whole new protocol for the purpose (I'm looking
>>>>>>>>> at /you/ AJP!).
>>>>>>>>
>>>>>>>> Indeed.
>>>>>>>>
>>>>>>>>> So why not use /the/ protocol that (a) exists and (b) is
>>>>>>>>> supported by every single product that currently supports this
>>>>>>>>> type of thing?
>>>>>>>>>
>>>>>>>>>> My support for any patch is going to depend on the specifics of
>>>>>>>>>> the patch.
>>>>>>>>>>
>>>>>>>>>> In addition to the comments in the BZ
>>>>>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>>>>>> other
>>>>>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>>>>>> RemoteIpFilter)
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> The whole point of PROXY is to kind of mix-together the
>>>>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>>>>>> headers for
>>>>>>>>> source-information) and the top-level idea of a Connector
>>>>>>>>> (something that binds to a socket and pushes bytes around).
>>>>>>>>>
>>>>>>>>> The confusing thing here is that those two jobs are performed at
>>>>>>>>> relatively different levels in Tomcat at the moment, as I
>>>>>>>>> understand things.
>>>>>>>>
>>>>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>>>>>> higher level because that is where they sit but the data
>>>>>>>> originates from the SocketWrapper.
>>>>>>>>
>>>>>>>>> If some kind of UberConnector could be built which essentially
>>>>>>>>> does something like the following, it would be ideal:
>>>>>>>>>
>>>>>>>>> public void accept(Socket s) {
>>>>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>>>>>
>>>>>>>>> Connector realConnector = getRealConnector();
>>>>>>>>>
>>>>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>>>>>
>>>>>>>>> realConnector.takeItAway(s); }
>>>>>>>>>
>>>>>>>>> I'm sure there are other pieces of information that would be good
>>>>>>>>> to pass-through, but the identity of the remote client is the
>>>>>>>>> most interesting one.
>>>>>>>>
>>>>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
>>>>>>>> use the SocketWrapper rather than the Connector and to do it in a
>>>>>>>> slightly different place. The Acceptor is too early as we want to
>>>>>>>> do as little as possible on the Acceptor thread.
>>>>>>>>
>>>>>>>>>> - needs to be implemented for all Connectors
>>>>>>>>>
>>>>>>>>> I hope not. The connectors should be able to just have a thin
>>>>>>>>> layer in front of them "sipping" the header off the beginning of
>>>>>>>>> the connection.
>>>>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>>>>>> works/should work", but conceptually it "seems easy". That may
>>>>>>>>> not translate into "easy implementation" or it may mean "tons of
>>>>>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>>>>>
>>>>>>>> My point was that the provided patch only implements this for NIO.
>>>>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
>>>>>>>> a lot more difficult to implement and I'd be happy not
>>>>>>>> implementing it for APR/Native.
>>>>>>>>
>>>>>>>>>> - I'd expect it to look more like the SNI processing
>>>>>>>>>
>>>>>>>>> SNI processing is very connector-dependent, of course, because
>>>>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
>>>>>>>>> anything.
>>>>>>>>> So if it can be implemented as something that can just "sit in
>>>>>>>>> front of"
>>>>>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>>>>>> done separately and globally.
>>>>>>>>
>>>>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>>>>>
>>>>>>>> SNI is handled independently of implementation and I think PROXY
>>>>>>>> should be handled the same way. They also sit at almost the same
>>>>>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>>>>>> could be implemented within the existing handshake() method but I
>>>>>>>> think it would be much cleaner in a separate method.
>>>>>>>>
>>>>>>>> Without looking at it too closely I think the implementation would
>>>>>>>> look something like:
>>>>>>>>
>>>>>>>> - a new method on SocketWrapperBase that
>>>>>>>> - checks if PROXY is enabled
>>>>>>>> - returns immediately if PROXY is not enabled or has already
>>>>>>>> been parsed
>>>>>>>> - uses a new utility class (or classes) to parse the header
>>>>>>>> (reading via the read() methods on SocketWrapperBase)
>>>>>>>> - sets the cached values for remoteAddr, remoteHost,
>>>>>>>> remotePort etc
>>>>>>>> - The SocketProcessor.doRun() implementations add a call to this
>>>>>>>> new
>>>>>>>> method just before the TLS handshake
>>>>>>>>
>>>>>>>> If we want to support the TLS information then a little additional
>>>>>>>> refactoring will be required (probably to cache the result of
>>>>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>>>>>> insert a PROXY specific SSLSupport implementation.
>>>>>>>>
>>>>>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
>>>>>>>>> it!"
>>>>>>>>> :)
>>>>>>>>
>>>>>>>> :)
>>>>>>>>
>>>>>>>> Actually with the patch that has already been provided and the
>>>>>>>> suggested implementation outline above I don't think there is too
>>>>>>>> much work to do.
>>>>>>>>
>>>>>>>>>> Generally, I don't think implementing this is going to be
>>>>>>>>>> possible as some sort of plug-in.
>>>>>>>>>
>>>>>>>>> +1 Unless the plug-in is "a whole new set of
>>>>>>>>> protocol/endpoint/etc.
>>>>>>>>> handlers" which is a rather serious commitment.
>>>>>>>>
>>>>>>>> On reflection, with the approach above we probably could implement
>>>>>>>> this via a new plug-in framework but I am not sure it is worth the
>>>>>>>> effort at this point. Something to keep in mind if we have more
>>>>>>>> things wanting to integrate at this point in the processing chain.
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>> Fhttpd.apache.org
>> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
>> 40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0
>> search for "haproxy"
>>>>>>>>>
>>>>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>>>>>> Missed to ask this:
>>>>>>>>>>>
>>>>>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>>>>>> protocol
>>>>>>>> support?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amit
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Amit Pande
>>>>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>
>>>>>>>>>>> Chris, Mark,
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts on this?
>>>>>>>>>>>
>>>>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>>>>>> any concerns (specially security wise)?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amit
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>
>>>>>>>>>>> Just a side note, because we're also very interested in this
>>>>>>>>>>> patch!
>>>>>>>>>>>
>>>>>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
>>>>>>>>>>> the relevant/required information to tomcat. I believe we had
>>>>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
>>>>>>>>>>> patch didn't handle that case.
>>>>>>>>>>>
>>>>>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>>>>>> getting a significant boost in throughput and decrease in
>>>>>>>>>>> latency.
>>>>>>>>>>>
>>>>>>>>>>> +1 for this patch and willing to help out!
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>>>>>> <Am...@veritas.com.invalid>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>>>>>
>>>>>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>>>>>> attached in
>>>>>>>>>>>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0
>> ?
>>>>>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>>>>>
>>>>>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Amit
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
>>>>>>>>>>>> Tomcat
>>>>>>>>>>>>
>>>>>>>>>>>> Amit,
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
>>>>>>>>>>>>> TCP proxy e.g.
>>>>>>>>>>>>>
>>>>>>>>>>>> https://www/.
>>>>>>>>>>>> envoyproxy.io
>>>>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>>>>>> c
>>>>>>>>>>>> om
>>>>>>>> %7Ca
>>>>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
>>>>>>>>>>>> a
>>>>>>>>>>>> c
>>>>>>>>>>>> 32%7C0
>>>>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>>>>>>> L
>>>>>>>>>>>> j
>>>>>>>>>>>> AwMDAi
>>>>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>>>> &
>>>>>>>>>>>> s
>>>>>>>>>>>> data=W
>>>>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>>>>>> which supports the proxy protocol.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since there is not much action on this
>>>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
>>>>>>>>>>>> F
>>>>>>>>>>>> %25
>>>>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
>>>>>>>>>>>> c
>>>>>>>>>>>> 1
>>>>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
>>>>>>>>>>>> 0
>>>>>>>>>>>> %
>>>>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>>>>> D
>>>>>>>>>>>> A
>>>>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>>>>>>>>>>>> C
>>>>>>>>>>>> &
>>>>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
>>>>>>>>>>>> 0
>>>>>>>>>>>> pache.org
>>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
>>>>>>>> 5
>>>>>>>> b
>>>>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
>>>>>>>> 3
>>>>>>>> d
>>>>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>> D
>>>>>>>> %
>>>>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
>>>>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
>>>>>>>> is running behind HTTP proxies and not TCP proxies?
>>>>>>>>>>>>> Or does it mean that, Tomcat or applications running in
>>>>>>>>>>>>> Tomcat does not
>>>>>>>>>>>> need the remote client address information?
>>>>>>>>>>>>
>>>>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>>>>>
>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>> -chris
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>>>
>>>>>>>>>>>>> Amit,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>>>>>> enhancement
>>>>>>>>>>>> request.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://bz/.
>>>>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4
>>>>>>>>>>>>>> b
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> 87206
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
>>>>>>>>>>>>>> 9
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> 50613
>>>>>>>>>>>>>> 56
>>>>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>>>>>>>>>>>> l
>>>>>>>>>>>>>> u
>>>>>>>>>>>>>> MzIiL
>>>>>>>>>>>>>> CJ
>>>>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
>>>>>>>>>>>>>> t
>>>>>>>>>>>>>> L
>>>>>>>>>>>>>> qUzY9
>>>>>>>>>>>>>> JM
>>>>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>>>>>> pache.org
>>>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>>>>>> P
>>>>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> c0422
>>>>>>>>>>>>>> c4
>>>>>>>>>>>>>> c
>>>>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
>>>>>>>>>>>>>> T
>>>>>>>>>>>>>> W
>>>>>>>>>>>>>> FpbGZ
>>>>>>>>>>>>>> sb
>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>> Mn0%3
>>>>>>>>>>>>>> D%
>>>>>>>>>>>>>> 7
>>>>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
>>>>>>>>>>>>>> l
>>>>>>>>>>>>>> 4
>>>>>>>>>>>>>> mY%3D
>>>>>>>>>>>>>> &r
>>>>>>>>>>>>>> e
>>>>>>>>>>>>>> served=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>>>>>> releases?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>>>>>> it didn't
>>>>>>>>>>>> look too difficult. It does require Tomcat to handle the
>>>>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
>>>>>>>>>>>> thought that had been done at some point, but it may not have.
>>>>>>>>>>>> Handling the stream directly may have some other advantages as
>>>>>>>>>>>> well, though it definitely makes the code more complicated.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, since this was requested long time back and there is
>>>>>>>>>>>>>> no update, are there any other alternatives to pass the
>>>>>>>>>>>>>> client information from load balancer to Tomcat in
>>>>>>>>>>>>>> situations where there is no SSL termination at load balancer?
>>>>>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>>>>>> proxying
>>>>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -chris
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -
>>>>>>>>>>>>> -----
>>>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>> -
>>>>>>>>>>>> -
>>>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>>> -
>>>>>>>>>>>> -
>>>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
>>>>>>>>>>> see it as half full.
>>>>>>>>>>> Engineers, of course, understand the glass is twice as big as
>>>>>>>>>>> it needs to be.
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> ---- To unsubscribe, e-mail:
>>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
Mark thank you again for your leadership and setting expectations. I'm
going to commit to working on this with anyone else that wants to help with
the goal of a patch by year end. I want to nail the patch with minimal
rework that meets Tomcat project quality standards. To that end, I'll
attempt to summarize what you expect here and if you could comment and
correct my understanding that would be appreciated.
It sounds like you're satisfied with the ubiquity of the Proxy protocol and
that it has an RFC
We'll target just implementing the latest version of the Proxy protocol
We'll implement a "TrustedProxies" feature similar to what the Remote IP
Valve does
We'll implement a, or modify the RemoteIp, valve to be able to set the
remote IP from Proxy protocol headers
We'll follow the RFC spec and reject any request that does a proper Proxy
protocol header
I'm particularly interested in the Proxy protocol over Unix Domain Sockets,
so expect to see a lot of the work focused on this, but accepting Proxy
Protocol over TCP looks to be quite important from the comments on this
email chain
If I may ask two things:
Can you summarize your desired implementation? What point in the stack
should we target to implement this?
One thing I'm not familiar with on Tomcat is the testing expectations. If
you can point to a set of unit tests and a set of integration tests and say
"Do it like this"
Anything else on the original patch you liked/didn't like? (
https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)
Thank you,
On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas <ma...@apache.org> wrote:
> On 28/08/2023 18:44, Amit Pande wrote:
> > Oh, sure. So, what would be the best way to get some conclusion on this
> thread?
>
> Provide a patch for review based on the feedback provided here and in
> the BZ issue.
>
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the
> ticket isn't updated for long. Perhaps add comments/ask the folks on user
> list to vote?
>
> That is more likely to irritate folks rather than encourage them to help
> you progress your patch.
>
> Mark
>
>
> >
> > Thanks,
> > Amit
> >
> > -----Original Message-----
> > From: Mark Thomas <ma...@apache.org>
> > Sent: Monday, August 28, 2023 11:20 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> >
> > CAUTION: This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe. If you believe this is a phishing email, use the
> Report to Cybersecurity icon in Outlook.
> >
> >
> >
> > 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> >
> >> Mark,
> >>
> >> Just checking - Did this issue get discussed in any of the core
> >> members' meeting?
> >
> > There are no such meetings. Discussion happens on the mailing lists.
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >> Amit
> >>
> >> -----Original Message-----
> >> From: Amit Pande
> >> Sent: Monday, July 31, 2023 9:29 AM
> >> To: Tomcat Users List <us...@tomcat.apache.org>
> >> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> Yes, understood.
> >>
> >> Thank you for clarifying. Even I was referring to initial consensus
> >> without any timeline or approach conclusion.
> >>
> >> Thanks,
> >> Amit
> >>
> >> -----Original Message-----
> >> From: Mark Thomas <ma...@apache.org>
> >> Sent: Friday, July 28, 2023 2:48 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> On 28/07/2023 19:21, Amit Pande wrote:
> >>> Thank you all for the valuable discussion on this topic.
> >>>
> >>> Is it okay to say that we're agreeing to adding proxy protocol
> >>> support in Tomcat?
> >>
> >> I think that is a little too strong. At this point there is a proposed
> >> approach and no one is objecting but until there is an actual patch to
> >> discuss...
> >>
> >> Keep in mind that any committer can veto a change.
> >>
> >> My sense is that it should be possible to implement this feature while
> >> addressing any concerns that may be raised but it is not guaranteed.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -----Original Message-----
> >>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>> Sent: Thursday, July 27, 2023 4:13 PM
> >>> To: users@tomcat.apache.org
> >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> All,
> >>>
> >>> On 7/27/23 12:39, Mark Thomas wrote:
> >>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
> >>>>> On the topic of security, may we consider a trustedProxies setting?
> >>>>
> >>>> Seems reasonable.
> >>>
> >>> We should probably look at what httpd did for all of this.
> >>>
> >>> -chris
> >>>
> >>>>> This
> >>>>> would be an analog to the internalProxies setting on RemoteIpValve.
> >>>>> It would need to be able to function with APR/NIO listening in a
> >>>>> Unix Domain Socket.
> >>>>>
> >>>>> I'm not sure if this is super useful, but the goal would be an
> >>>>> added layer of security to prevent Proxy Protocol header injection.
> >>>>>
> >>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
> >>>>>>> Mark,
> >>>>>>>
> >>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
> >>>>>>>> I'm not a huge fan of this feature in general. I prefer
> >>>>>>>> supporting features backed by specifications rather than vendor
> >>>>>>>> specific hacks.
> >>>>>>>
> >>>>>>> I think the PROXY protocol is fairly standard, even if it's not
> >>>>>>> backed by an RFC. It's published by haproxy, but supported by
> >>>>>>> nginx,
> >>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
> >>>>>> https://ww/
> >>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
> >>>>>> s
> >>>>>> -
> >>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
> >>>>>> f
> >>>>>> a
> >>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
> >>>>>> 2
> >>>>>> 6
> >>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> >>>>>> V
> >>>>>> 2
> >>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
> >>>>>> a
> >>>>>> 0
> >>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
> >>>>>> ).
> >>>>>>
> >>>>>> ACK. That reduces my concerns somewhat.
> >>>>>>
> >>>>>>> Well, the reality is that people want to use this in the real
> >>>>>>> world and this is essentially the only way to do it, barring
> >>>>>>> coming up with a whole new protocol for the purpose (I'm looking
> >>>>>>> at /you/ AJP!).
> >>>>>>
> >>>>>> Indeed.
> >>>>>>
> >>>>>>> So why not use /the/ protocol that (a) exists and (b) is
> >>>>>>> supported by every single product that currently supports this
> >>>>>>> type of thing?
> >>>>>>>
> >>>>>>>> My support for any patch is going to depend on the specifics of
> >>>>>>>> the patch.
> >>>>>>>>
> >>>>>>>> In addition to the comments in the BZ
> >>>>>>>> - exposing the data as a request attribute is inconsistent with
> >>>>>>>> other
> >>>>>>>> mechanisms that solve the same problem (e.g. see
> >>>>>>>> RemoteIpFilter)
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> The whole point of PROXY is to kind of mix-together the
> >>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
> >>>>>>> headers for
> >>>>>>> source-information) and the top-level idea of a Connector
> >>>>>>> (something that binds to a socket and pushes bytes around).
> >>>>>>>
> >>>>>>> The confusing thing here is that those two jobs are performed at
> >>>>>>> relatively different levels in Tomcat at the moment, as I
> >>>>>>> understand things.
> >>>>>>
> >>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
> >>>>>> higher level because that is where they sit but the data
> >>>>>> originates from the SocketWrapper.
> >>>>>>
> >>>>>>> If some kind of UberConnector could be built which essentially
> >>>>>>> does something like the following, it would be ideal:
> >>>>>>>
> >>>>>>> public void accept(Socket s) {
> >>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
> >>>>>>>
> >>>>>>> Connector realConnector = getRealConnector();
> >>>>>>>
> >>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> >>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
> >>>>>>>
> >>>>>>> realConnector.takeItAway(s); }
> >>>>>>>
> >>>>>>> I'm sure there are other pieces of information that would be good
> >>>>>>> to pass-through, but the identity of the remote client is the
> >>>>>>> most interesting one.
> >>>>>>
> >>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
> >>>>>> use the SocketWrapper rather than the Connector and to do it in a
> >>>>>> slightly different place. The Acceptor is too early as we want to
> >>>>>> do as little as possible on the Acceptor thread.
> >>>>>>
> >>>>>>>> - needs to be implemented for all Connectors
> >>>>>>>
> >>>>>>> I hope not. The connectors should be able to just have a thin
> >>>>>>> layer in front of them "sipping" the header off the beginning of
> >>>>>>> the connection.
> >>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
> >>>>>>> and so I don't want to appear to be telling you (Mark) "how it
> >>>>>>> works/should work", but conceptually it "seems easy". That may
> >>>>>>> not translate into "easy implementation" or it may mean "tons of
> >>>>>>> refactoring that we wouldn't need if we didn't care that much."
> >>>>>>
> >>>>>> My point was that the provided patch only implements this for NIO.
> >>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
> >>>>>> a lot more difficult to implement and I'd be happy not
> >>>>>> implementing it for APR/Native.
> >>>>>>
> >>>>>>>> - I'd expect it to look more like the SNI processing
> >>>>>>>
> >>>>>>> SNI processing is very connector-dependent, of course, because
> >>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
> >>>>>>> anything.
> >>>>>>> So if it can be implemented as something that can just "sit in
> >>>>>>> front of"
> >>>>>>> *any* connector now or in the future of Tomcat, that would be
> >>>>>>> ideal. It could definitely be implemented as an "optional feature"
> >>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
> >>>>>>> done separately and globally.
> >>>>>>
> >>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
> >>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
> >>>>>>
> >>>>>> SNI is handled independently of implementation and I think PROXY
> >>>>>> should be handled the same way. They also sit at almost the same
> >>>>>> point in the processing (PROXY needs to be first). PROXY parsing
> >>>>>> could be implemented within the existing handshake() method but I
> >>>>>> think it would be much cleaner in a separate method.
> >>>>>>
> >>>>>> Without looking at it too closely I think the implementation would
> >>>>>> look something like:
> >>>>>>
> >>>>>> - a new method on SocketWrapperBase that
> >>>>>> - checks if PROXY is enabled
> >>>>>> - returns immediately if PROXY is not enabled or has already
> >>>>>> been parsed
> >>>>>> - uses a new utility class (or classes) to parse the header
> >>>>>> (reading via the read() methods on SocketWrapperBase)
> >>>>>> - sets the cached values for remoteAddr, remoteHost,
> >>>>>> remotePort etc
> >>>>>> - The SocketProcessor.doRun() implementations add a call to this
> >>>>>> new
> >>>>>> method just before the TLS handshake
> >>>>>>
> >>>>>> If we want to support the TLS information then a little additional
> >>>>>> refactoring will be required (probably to cache the result of
> >>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
> >>>>>> insert a PROXY specific SSLSupport implementation.
> >>>>>>
> >>>>>>> Again, I'm speaking from a position of profound ignorance, here.
> >>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
> >>>>>>> it!"
> >>>>>>> :)
> >>>>>>
> >>>>>> :)
> >>>>>>
> >>>>>> Actually with the patch that has already been provided and the
> >>>>>> suggested implementation outline above I don't think there is too
> >>>>>> much work to do.
> >>>>>>
> >>>>>>>> Generally, I don't think implementing this is going to be
> >>>>>>>> possible as some sort of plug-in.
> >>>>>>>
> >>>>>>> +1 Unless the plug-in is "a whole new set of
> >>>>>>> protocol/endpoint/etc.
> >>>>>>> handlers" which is a rather serious commitment.
> >>>>>>
> >>>>>> On reflection, with the approach above we probably could implement
> >>>>>> this via a new plug-in framework but I am not sure it is worth the
> >>>>>> effort at this point. Something to keep in mind if we have more
> >>>>>> things wanting to integrate at this point in the processing chain.
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>>
> >>>>>>> -chris
> >>>>>>>
> >>>>>>> [1]
> >>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>> Fhttpd.apache.org
> %2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%
> 40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0
> search for "haproxy"
> >>>>>>>
> >>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
> >>>>>>>>> Missed to ask this:
> >>>>>>>>>
> >>>>>>>>> Looking the patch, it involves modifying Tomcat code.
> >>>>>>>>> Was wondering if it would be possible to refactor this patch
> >>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
> >>>>>>>>> protocol
> >>>>>> support?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Amit
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Amit Pande
> >>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
> >>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>
> >>>>>>>>> Chris, Mark,
> >>>>>>>>>
> >>>>>>>>> Any thoughts on this?
> >>>>>>>>>
> >>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
> >>>>>>>>> any concerns (specially security wise)?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Amit
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
> >>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
> >>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>
> >>>>>>>>> Just a side note, because we're also very interested in this
> >>>>>>>>> patch!
> >>>>>>>>>
> >>>>>>>>> Awhile back, I was successfully able to apply this patch and
> >>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
> >>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
> >>>>>>>>> the relevant/required information to tomcat. I believe we had
> >>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
> >>>>>>>>> patch didn't handle that case.
> >>>>>>>>>
> >>>>>>>>> I can find my notes from that experiment, but I do remember
> >>>>>>>>> getting a significant boost in throughput and decrease in
> >>>>>>>>> latency.
> >>>>>>>>>
> >>>>>>>>> +1 for this patch and willing to help out!
> >>>>>>>>>
> >>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> >>>>>>>>> <Am...@veritas.com.invalid>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thank you, Chris, again for inputs.
> >>>>>>>>>> And sorry to circle back on this, late.
> >>>>>>>>>>
> >>>>>>>>>> One related question is - does it make sense to use the patch
> >>>>>>>>>> attached in
> >>>>>>>>>>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0
> ?
> >>>>>>>>>> And potentially, get it integrated into Tomcat versions?
> >>>>>>>>>>
> >>>>>>>>>> There are concerns from Mark about using the patch in its
> >>>>>>>>>> current state, but I see last comment (#24) on the issue and
> >>>>>>>>>> looks like there are some more points to be concluded.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Amit
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
> >>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
> >>>>>>>>>> Tomcat
> >>>>>>>>>>
> >>>>>>>>>> Amit,
> >>>>>>>>>>
> >>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
> >>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
> >>>>>>>>>>> TCP proxy e.g.
> >>>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> envoyproxy.io
> >>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> >>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
> >>>>>>>>>> c
> >>>>>>>>>> om
> >>>>>> %7Ca
> >>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
> >>>>>>>>>> a
> >>>>>>>>>> c
> >>>>>>>>>> 32%7C0
> >>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> >>>>>>>>>> L
> >>>>>>>>>> j
> >>>>>>>>>> AwMDAi
> >>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >>>>>>>>>> &
> >>>>>>>>>> s
> >>>>>>>>>> data=W
> >>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> >>>>>>>>>> which supports the proxy protocol.
> >>>>>>>>>>>
> >>>>>>>>>>> Since there is not much action on this
> >>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
> >>>>>>>>>> F
> >>>>>>>>>> %25
> >>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
> >>>>>>>>>> c
> >>>>>>>>>> 1
> >>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
> >>>>>>>>>> 0
> >>>>>>>>>> %
> >>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>>>>>>>> D
> >>>>>>>>>> A
> >>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >>>>>>>>>> C
> >>>>>>>>>> &
> >>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
> >>>>>>>>>> 0
> >>>>>>>>>> pache.org
> >>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
> >>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
> >>>>>> 5
> >>>>>> b
> >>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
> >>>>>> 3
> >>>>>> d
> >>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>> D
> >>>>>> %
> >>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
> >>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
> >>>>>> is running behind HTTP proxies and not TCP proxies?
> >>>>>>>>>>> Or does it mean that, Tomcat or applications running in
> >>>>>>>>>>> Tomcat does not
> >>>>>>>>>> need the remote client address information?
> >>>>>>>>>>
> >>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
> >>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
> >>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
> >>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
> >>>>>>>>>> multiple services behind my reverse-proxy which run in
> >>>>>>>>>> different places. It's not just s dumb pass-through.
> >>>>>>>>>>
> >>>>>>>>>> Hope that helps,
> >>>>>>>>>> -chris
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
> >>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>>>>>>>
> >>>>>>>>>>> Amit,
> >>>>>>>>>>>
> >>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
> >>>>>>>>>>>> We have a similar requirement as mentioned in the below
> >>>>>>>>>>>> enhancement
> >>>>>>>>>> request.
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://bz/.
> >>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4
> >>>>>>>>>>>> b
> >>>>>>>>>>>> 7
> >>>>>>>>>>>> 87206
> >>>>>>>>>>>> 08
> >>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
> >>>>>>>>>>>> 9
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> 50613
> >>>>>>>>>>>> 56
> >>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> >>>>>>>>>>>> l
> >>>>>>>>>>>> u
> >>>>>>>>>>>> MzIiL
> >>>>>>>>>>>> CJ
> >>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
> >>>>>>>>>>>> t
> >>>>>>>>>>>> L
> >>>>>>>>>>>> qUzY9
> >>>>>>>>>>>> JM
> >>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >>>>>>>>>>>> pache.org
> >>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >>>>>>>>>>>> P
> >>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e
> >>>>>>>>>>>> 1
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> c0422
> >>>>>>>>>>>> c4
> >>>>>>>>>>>> c
> >>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
> >>>>>>>>>>>> T
> >>>>>>>>>>>> W
> >>>>>>>>>>>> FpbGZ
> >>>>>>>>>>>> sb
> >>>>>>>>>>>> 3
> >>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> >>>>>>>>>>>> I
> >>>>>>>>>>>> 6
> >>>>>>>>>>>> Mn0%3
> >>>>>>>>>>>> D%
> >>>>>>>>>>>> 7
> >>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
> >>>>>>>>>>>> l
> >>>>>>>>>>>> 4
> >>>>>>>>>>>> mY%3D
> >>>>>>>>>>>> &r
> >>>>>>>>>>>> e
> >>>>>>>>>>>> served=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
> >>>>>>>>>>>> releases?
> >>>>>>>>>>>
> >>>>>>>>>>> Nothing at the moment that I know of.
> >>>>>>>>>>>
> >>>>>>>>>>> I thought that markt had looked at this a while back and said
> >>>>>>>>>>> it didn't
> >>>>>>>>>> look too difficult. It does require Tomcat to handle the
> >>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
> >>>>>>>>>> thought that had been done at some point, but it may not have.
> >>>>>>>>>> Handling the stream directly may have some other advantages as
> >>>>>>>>>> well, though it definitely makes the code more complicated.
> >>>>>>>>>>>
> >>>>>>>>>>>> Also, since this was requested long time back and there is
> >>>>>>>>>>>> no update, are there any other alternatives to pass the
> >>>>>>>>>>>> client information from load balancer to Tomcat in
> >>>>>>>>>>>> situations where there is no SSL termination at load balancer?
> >>>>>>>>>>> You mean like a network load balancer where the lb is just
> >>>>>>>>>>> proxying
> >>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
> >>>>>>>>>> really is the best way to do that, honestly.
> >>>>>>>>>>>
> >>>>>>>>>>> -chris
> >>>>>>>>>>>
> >>>>>>>>>>> -------------------------------------------------------------
> >>>>>>>>>>> -
> >>>>>>>>>>> -
> >>>>>>>>>>> -----
> >>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -------------------------------------------------------------
> >>>>>>>>>>> -
> >>>>>>>>>>> -
> >>>>>>>>>>> -----
> >>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --------------------------------------------------------------
> >>>>>>>>>> -
> >>>>>>>>>> -
> >>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --------------------------------------------------------------
> >>>>>>>>>> -
> >>>>>>>>>> -
> >>>>>>>>>> ----- To unsubscribe, e-mail:
> >>>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Jonathan | exabrial@gmail.com
> >>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
> >>>>>>>>> see it as half full.
> >>>>>>>>> Engineers, of course, understand the glass is twice as big as
> >>>>>>>>> it needs to be.
> >>>>>>>>>
> >>>>>>>>> ---------------------------------------------------------------
> >>>>>>>>> -
> >>>>>>>>> -
> >>>>>>>>> ---- To unsubscribe, e-mail:
> >>>>>>>>> users-unsubscribe@tomcat.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------------
> >>>>>>>> -
> >>>>>>>> -
> >>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>> -----------------------------------------------------------------
> >>>>>>> -
> >>>>>>> -
> >>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------------
> >>>>>> -
> >>>>>> -
> >>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 28/08/2023 18:44, Amit Pande wrote:
> Oh, sure. So, what would be the best way to get some conclusion on this thread?
Provide a patch for review based on the feedback provided here and in
the BZ issue.
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the ticket isn't updated for long. Perhaps add comments/ask the folks on user list to vote?
That is more likely to irritate folks rather than encourage them to help
you progress your patch.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Mark Thomas <ma...@apache.org>
> Sent: Monday, August 28, 2023 11:20 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
>
> CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook.
>
>
>
> 28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
>
>> Mark,
>>
>> Just checking - Did this issue get discussed in any of the core
>> members' meeting?
>
> There are no such meetings. Discussion happens on the mailing lists.
>
> Mark
>
>
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Amit Pande
>> Sent: Monday, July 31, 2023 9:29 AM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> Yes, understood.
>>
>> Thank you for clarifying. Even I was referring to initial consensus
>> without any timeline or approach conclusion.
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Mark Thomas <ma...@apache.org>
>> Sent: Friday, July 28, 2023 2:48 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> On 28/07/2023 19:21, Amit Pande wrote:
>>> Thank you all for the valuable discussion on this topic.
>>>
>>> Is it okay to say that we're agreeing to adding proxy protocol
>>> support in Tomcat?
>>
>> I think that is a little too strong. At this point there is a proposed
>> approach and no one is objecting but until there is an actual patch to
>> discuss...
>>
>> Keep in mind that any committer can veto a change.
>>
>> My sense is that it should be possible to implement this feature while
>> addressing any concerns that may be raised but it is not guaranteed.
>>
>> Mark
>>
>>
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>> Sent: Thursday, July 27, 2023 4:13 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>> All,
>>>
>>> On 7/27/23 12:39, Mark Thomas wrote:
>>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>>>> On the topic of security, may we consider a trustedProxies setting?
>>>>
>>>> Seems reasonable.
>>>
>>> We should probably look at what httpd did for all of this.
>>>
>>> -chris
>>>
>>>>> This
>>>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>>>> It would need to be able to function with APR/NIO listening in a
>>>>> Unix Domain Socket.
>>>>>
>>>>> I'm not sure if this is super useful, but the goal would be an
>>>>> added layer of security to prevent Proxy Protocol header injection.
>>>>>
>>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>>>> Mark,
>>>>>>>
>>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>>>> supporting features backed by specifications rather than vendor
>>>>>>>> specific hacks.
>>>>>>>
>>>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>>>> nginx,
>>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>>>> https://ww/
>>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
>>>>>> s
>>>>>> -
>>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
>>>>>> f
>>>>>> a
>>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
>>>>>> 2
>>>>>> 6
>>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>>>> V
>>>>>> 2
>>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
>>>>>> a
>>>>>> 0
>>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>>>> ).
>>>>>>
>>>>>> ACK. That reduces my concerns somewhat.
>>>>>>
>>>>>>> Well, the reality is that people want to use this in the real
>>>>>>> world and this is essentially the only way to do it, barring
>>>>>>> coming up with a whole new protocol for the purpose (I'm looking
>>>>>>> at /you/ AJP!).
>>>>>>
>>>>>> Indeed.
>>>>>>
>>>>>>> So why not use /the/ protocol that (a) exists and (b) is
>>>>>>> supported by every single product that currently supports this
>>>>>>> type of thing?
>>>>>>>
>>>>>>>> My support for any patch is going to depend on the specifics of
>>>>>>>> the patch.
>>>>>>>>
>>>>>>>> In addition to the comments in the BZ
>>>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>>>> other
>>>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>>>> RemoteIpFilter)
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> The whole point of PROXY is to kind of mix-together the
>>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>>>> headers for
>>>>>>> source-information) and the top-level idea of a Connector
>>>>>>> (something that binds to a socket and pushes bytes around).
>>>>>>>
>>>>>>> The confusing thing here is that those two jobs are performed at
>>>>>>> relatively different levels in Tomcat at the moment, as I
>>>>>>> understand things.
>>>>>>
>>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>>>> higher level because that is where they sit but the data
>>>>>> originates from the SocketWrapper.
>>>>>>
>>>>>>> If some kind of UberConnector could be built which essentially
>>>>>>> does something like the following, it would be ideal:
>>>>>>>
>>>>>>> public void accept(Socket s) {
>>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>>>
>>>>>>> Connector realConnector = getRealConnector();
>>>>>>>
>>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>>>
>>>>>>> realConnector.takeItAway(s); }
>>>>>>>
>>>>>>> I'm sure there are other pieces of information that would be good
>>>>>>> to pass-through, but the identity of the remote client is the
>>>>>>> most interesting one.
>>>>>>
>>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
>>>>>> use the SocketWrapper rather than the Connector and to do it in a
>>>>>> slightly different place. The Acceptor is too early as we want to
>>>>>> do as little as possible on the Acceptor thread.
>>>>>>
>>>>>>>> - needs to be implemented for all Connectors
>>>>>>>
>>>>>>> I hope not. The connectors should be able to just have a thin
>>>>>>> layer in front of them "sipping" the header off the beginning of
>>>>>>> the connection.
>>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>>>> works/should work", but conceptually it "seems easy". That may
>>>>>>> not translate into "easy implementation" or it may mean "tons of
>>>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>>>
>>>>>> My point was that the provided patch only implements this for NIO.
>>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
>>>>>> a lot more difficult to implement and I'd be happy not
>>>>>> implementing it for APR/Native.
>>>>>>
>>>>>>>> - I'd expect it to look more like the SNI processing
>>>>>>>
>>>>>>> SNI processing is very connector-dependent, of course, because
>>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
>>>>>>> anything.
>>>>>>> So if it can be implemented as something that can just "sit in
>>>>>>> front of"
>>>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>>>> done separately and globally.
>>>>>>
>>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>>>
>>>>>> SNI is handled independently of implementation and I think PROXY
>>>>>> should be handled the same way. They also sit at almost the same
>>>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>>>> could be implemented within the existing handshake() method but I
>>>>>> think it would be much cleaner in a separate method.
>>>>>>
>>>>>> Without looking at it too closely I think the implementation would
>>>>>> look something like:
>>>>>>
>>>>>> - a new method on SocketWrapperBase that
>>>>>> - checks if PROXY is enabled
>>>>>> - returns immediately if PROXY is not enabled or has already
>>>>>> been parsed
>>>>>> - uses a new utility class (or classes) to parse the header
>>>>>> (reading via the read() methods on SocketWrapperBase)
>>>>>> - sets the cached values for remoteAddr, remoteHost,
>>>>>> remotePort etc
>>>>>> - The SocketProcessor.doRun() implementations add a call to this
>>>>>> new
>>>>>> method just before the TLS handshake
>>>>>>
>>>>>> If we want to support the TLS information then a little additional
>>>>>> refactoring will be required (probably to cache the result of
>>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>>>> insert a PROXY specific SSLSupport implementation.
>>>>>>
>>>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
>>>>>>> it!"
>>>>>>> :)
>>>>>>
>>>>>> :)
>>>>>>
>>>>>> Actually with the patch that has already been provided and the
>>>>>> suggested implementation outline above I don't think there is too
>>>>>> much work to do.
>>>>>>
>>>>>>>> Generally, I don't think implementing this is going to be
>>>>>>>> possible as some sort of plug-in.
>>>>>>>
>>>>>>> +1 Unless the plug-in is "a whole new set of
>>>>>>> protocol/endpoint/etc.
>>>>>>> handlers" which is a rather serious commitment.
>>>>>>
>>>>>> On reflection, with the approach above we probably could implement
>>>>>> this via a new plug-in framework but I am not sure it is worth the
>>>>>> effort at this point. Something to keep in mind if we have more
>>>>>> things wanting to integrate at this point in the processing chain.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>>
>>>>>>> -chris
>>>>>>>
>>>>>>> [1]
>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>> Fhttpd.apache.org%2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0 search for "haproxy"
>>>>>>>
>>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>>>> Missed to ask this:
>>>>>>>>>
>>>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>>>> protocol
>>>>>> support?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Amit
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Amit Pande
>>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Chris, Mark,
>>>>>>>>>
>>>>>>>>> Any thoughts on this?
>>>>>>>>>
>>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>>>> any concerns (specially security wise)?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Amit
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Just a side note, because we're also very interested in this
>>>>>>>>> patch!
>>>>>>>>>
>>>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
>>>>>>>>> the relevant/required information to tomcat. I believe we had
>>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
>>>>>>>>> patch didn't handle that case.
>>>>>>>>>
>>>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>>>> getting a significant boost in throughput and decrease in
>>>>>>>>> latency.
>>>>>>>>>
>>>>>>>>> +1 for this patch and willing to help out!
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>>>> <Am...@veritas.com.invalid>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>>>
>>>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>>>> attached in
>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0 ?
>>>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>>>
>>>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Amit
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
>>>>>>>>>> Tomcat
>>>>>>>>>>
>>>>>>>>>> Amit,
>>>>>>>>>>
>>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
>>>>>>>>>>> TCP proxy e.g.
>>>>>>>>>>>
>>>>>>>>>> https://www/.
>>>>>>>>>> envoyproxy.io
>>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>>>> c
>>>>>>>>>> om
>>>>>> %7Ca
>>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
>>>>>>>>>> a
>>>>>>>>>> c
>>>>>>>>>> 32%7C0
>>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>>>>> L
>>>>>>>>>> j
>>>>>>>>>> AwMDAi
>>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &
>>>>>>>>>> s
>>>>>>>>>> data=W
>>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>>>> which supports the proxy protocol.
>>>>>>>>>>>
>>>>>>>>>>> Since there is not much action on this
>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
>>>>>>>>>> F
>>>>>>>>>> %25
>>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
>>>>>>>>>> c
>>>>>>>>>> 1
>>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
>>>>>>>>>> 0
>>>>>>>>>> %
>>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>>> D
>>>>>>>>>> A
>>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>>>>>>>>>> C
>>>>>>>>>> &
>>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
>>>>>>>>>> 0
>>>>>>>>>> pache.org
>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
>>>>>> 5
>>>>>> b
>>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
>>>>>> 3
>>>>>> d
>>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>> D
>>>>>> %
>>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
>>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
>>>>>> is running behind HTTP proxies and not TCP proxies?
>>>>>>>>>>> Or does it mean that, Tomcat or applications running in
>>>>>>>>>>> Tomcat does not
>>>>>>>>>> need the remote client address information?
>>>>>>>>>>
>>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>>>
>>>>>>>>>> Hope that helps,
>>>>>>>>>> -chris
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>>
>>>>>>>>>>> Amit,
>>>>>>>>>>>
>>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>>>> enhancement
>>>>>>>>>> request.
>>>>>>>>>>>>
>>>>>>>>>>>> https://bz/.
>>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4
>>>>>>>>>>>> b
>>>>>>>>>>>> 7
>>>>>>>>>>>> 87206
>>>>>>>>>>>> 08
>>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
>>>>>>>>>>>> 9
>>>>>>>>>>>> 3
>>>>>>>>>>>> 50613
>>>>>>>>>>>> 56
>>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>>>>>>>>>> l
>>>>>>>>>>>> u
>>>>>>>>>>>> MzIiL
>>>>>>>>>>>> CJ
>>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
>>>>>>>>>>>> t
>>>>>>>>>>>> L
>>>>>>>>>>>> qUzY9
>>>>>>>>>>>> JM
>>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>>>> pache.org
>>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>>>> P
>>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e
>>>>>>>>>>>> 1
>>>>>>>>>>>> 3
>>>>>>>>>>>> c0422
>>>>>>>>>>>> c4
>>>>>>>>>>>> c
>>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
>>>>>>>>>>>> T
>>>>>>>>>>>> W
>>>>>>>>>>>> FpbGZ
>>>>>>>>>>>> sb
>>>>>>>>>>>> 3
>>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>>>>>>>>> I
>>>>>>>>>>>> 6
>>>>>>>>>>>> Mn0%3
>>>>>>>>>>>> D%
>>>>>>>>>>>> 7
>>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
>>>>>>>>>>>> l
>>>>>>>>>>>> 4
>>>>>>>>>>>> mY%3D
>>>>>>>>>>>> &r
>>>>>>>>>>>> e
>>>>>>>>>>>> served=0
>>>>>>>>>>>>
>>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>>>> releases?
>>>>>>>>>>>
>>>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>>>
>>>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>>>> it didn't
>>>>>>>>>> look too difficult. It does require Tomcat to handle the
>>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
>>>>>>>>>> thought that had been done at some point, but it may not have.
>>>>>>>>>> Handling the stream directly may have some other advantages as
>>>>>>>>>> well, though it definitely makes the code more complicated.
>>>>>>>>>>>
>>>>>>>>>>>> Also, since this was requested long time back and there is
>>>>>>>>>>>> no update, are there any other alternatives to pass the
>>>>>>>>>>>> client information from load balancer to Tomcat in
>>>>>>>>>>>> situations where there is no SSL termination at load balancer?
>>>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>>>> proxying
>>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>>>
>>>>>>>>>>> -chris
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> -----
>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> -----
>>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
>>>>>>>>> see it as half full.
>>>>>>>>> Engineers, of course, understand the glass is twice as big as
>>>>>>>>> it needs to be.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> ---- To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Oh, sure. So, what would be the best way to get some conclusion on this thread?
https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the ticket isn't updated for long. Perhaps add comments/ask the folks on user list to vote?
Thanks,
Amit
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Monday, August 28, 2023 11:20 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook.
28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> Mark,
>
> Just checking - Did this issue get discussed in any of the core
> members' meeting?
There are no such meetings. Discussion happens on the mailing lists.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Amit Pande
> Sent: Monday, July 31, 2023 9:29 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Yes, understood.
>
> Thank you for clarifying. Even I was referring to initial consensus
> without any timeline or approach conclusion.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Mark Thomas <ma...@apache.org>
> Sent: Friday, July 28, 2023 2:48 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> On 28/07/2023 19:21, Amit Pande wrote:
>> Thank you all for the valuable discussion on this topic.
>>
>> Is it okay to say that we're agreeing to adding proxy protocol
>> support in Tomcat?
>
> I think that is a little too strong. At this point there is a proposed
> approach and no one is objecting but until there is an actual patch to
> discuss...
>
> Keep in mind that any committer can veto a change.
>
> My sense is that it should be possible to implement this feature while
> addressing any concerns that may be raised but it is not guaranteed.
>
> Mark
>
>
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Thursday, July 27, 2023 4:13 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> All,
>>
>> On 7/27/23 12:39, Mark Thomas wrote:
>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>>> On the topic of security, may we consider a trustedProxies setting?
>>>
>>> Seems reasonable.
>>
>> We should probably look at what httpd did for all of this.
>>
>> -chris
>>
>>>> This
>>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>>> It would need to be able to function with APR/NIO listening in a
>>>> Unix Domain Socket.
>>>>
>>>> I'm not sure if this is super useful, but the goal would be an
>>>> added layer of security to prevent Proxy Protocol header injection.
>>>>
>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
>>>> wrote:
>>>>
>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>>> Mark,
>>>>>>
>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>>> supporting features backed by specifications rather than vendor
>>>>>>> specific hacks.
>>>>>>
>>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>>> nginx,
>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>>> https://ww/
>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
>>>>> s
>>>>> -
>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
>>>>> f
>>>>> a
>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
>>>>> 2
>>>>> 6
>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>>> V
>>>>> 2
>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpIL
>>>>> a
>>>>> 0
>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>>> ).
>>>>>
>>>>> ACK. That reduces my concerns somewhat.
>>>>>
>>>>>> Well, the reality is that people want to use this in the real
>>>>>> world and this is essentially the only way to do it, barring
>>>>>> coming up with a whole new protocol for the purpose (I'm looking
>>>>>> at /you/ AJP!).
>>>>>
>>>>> Indeed.
>>>>>
>>>>>> So why not use /the/ protocol that (a) exists and (b) is
>>>>>> supported by every single product that currently supports this
>>>>>> type of thing?
>>>>>>
>>>>>>> My support for any patch is going to depend on the specifics of
>>>>>>> the patch.
>>>>>>>
>>>>>>> In addition to the comments in the BZ
>>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>>> other
>>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>>> RemoteIpFilter)
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> The whole point of PROXY is to kind of mix-together the
>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>>> headers for
>>>>>> source-information) and the top-level idea of a Connector
>>>>>> (something that binds to a socket and pushes bytes around).
>>>>>>
>>>>>> The confusing thing here is that those two jobs are performed at
>>>>>> relatively different levels in Tomcat at the moment, as I
>>>>>> understand things.
>>>>>
>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>>> higher level because that is where they sit but the data
>>>>> originates from the SocketWrapper.
>>>>>
>>>>>> If some kind of UberConnector could be built which essentially
>>>>>> does something like the following, it would be ideal:
>>>>>>
>>>>>> public void accept(Socket s) {
>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>>
>>>>>> Connector realConnector = getRealConnector();
>>>>>>
>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>>
>>>>>> realConnector.takeItAway(s); }
>>>>>>
>>>>>> I'm sure there are other pieces of information that would be good
>>>>>> to pass-through, but the identity of the remote client is the
>>>>>> most interesting one.
>>>>>
>>>>> Yes, that is the general idea. Just a couple of minor tweaks to
>>>>> use the SocketWrapper rather than the Connector and to do it in a
>>>>> slightly different place. The Acceptor is too early as we want to
>>>>> do as little as possible on the Acceptor thread.
>>>>>
>>>>>>> - needs to be implemented for all Connectors
>>>>>>
>>>>>> I hope not. The connectors should be able to just have a thin
>>>>>> layer in front of them "sipping" the header off the beginning of
>>>>>> the connection.
>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>>> works/should work", but conceptually it "seems easy". That may
>>>>>> not translate into "easy implementation" or it may mean "tons of
>>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>>
>>>>> My point was that the provided patch only implements this for NIO.
>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be
>>>>> a lot more difficult to implement and I'd be happy not
>>>>> implementing it for APR/Native.
>>>>>
>>>>>>> - I'd expect it to look more like the SNI processing
>>>>>>
>>>>>> SNI processing is very connector-dependent, of course, because
>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
>>>>>> anything.
>>>>>> So if it can be implemented as something that can just "sit in
>>>>>> front of"
>>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>>> done separately and globally.
>>>>>
>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>>
>>>>> SNI is handled independently of implementation and I think PROXY
>>>>> should be handled the same way. They also sit at almost the same
>>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>>> could be implemented within the existing handshake() method but I
>>>>> think it would be much cleaner in a separate method.
>>>>>
>>>>> Without looking at it too closely I think the implementation would
>>>>> look something like:
>>>>>
>>>>> - a new method on SocketWrapperBase that
>>>>> - checks if PROXY is enabled
>>>>> - returns immediately if PROXY is not enabled or has already
>>>>> been parsed
>>>>> - uses a new utility class (or classes) to parse the header
>>>>> (reading via the read() methods on SocketWrapperBase)
>>>>> - sets the cached values for remoteAddr, remoteHost,
>>>>> remotePort etc
>>>>> - The SocketProcessor.doRun() implementations add a call to this
>>>>> new
>>>>> method just before the TLS handshake
>>>>>
>>>>> If we want to support the TLS information then a little additional
>>>>> refactoring will be required (probably to cache the result of
>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>>> insert a PROXY specific SSLSupport implementation.
>>>>>
>>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
>>>>>> it!"
>>>>>> :)
>>>>>
>>>>> :)
>>>>>
>>>>> Actually with the patch that has already been provided and the
>>>>> suggested implementation outline above I don't think there is too
>>>>> much work to do.
>>>>>
>>>>>>> Generally, I don't think implementing this is going to be
>>>>>>> possible as some sort of plug-in.
>>>>>>
>>>>>> +1 Unless the plug-in is "a whole new set of
>>>>>> protocol/endpoint/etc.
>>>>>> handlers" which is a rather serious commitment.
>>>>>
>>>>> On reflection, with the approach above we probably could implement
>>>>> this via a new plug-in framework but I am not sure it is worth the
>>>>> effort at this point. Something to keep in mind if we have more
>>>>> things wanting to integrate at this point in the processing chain.
>>>>>
>>>>> Mark
>>>>>
>>>>>>
>>>>>> -chris
>>>>>>
>>>>>> [1]
>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fhttpd.apache.org%2Fdocs%2F2.4%2Fmod%2Fmod_remoteip.html&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1and8JWbfUqI%2F1vR1ZZPZEi%2FSWVNlqUpBb8bg668TcA%3D&reserved=0 search for "haproxy"
>>>>>>
>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>>> Missed to ask this:
>>>>>>>>
>>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>>> protocol
>>>>> support?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Amit Pande
>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Chris, Mark,
>>>>>>>>
>>>>>>>> Any thoughts on this?
>>>>>>>>
>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>>> any concerns (specially security wise)?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Just a side note, because we're also very interested in this
>>>>>>>> patch!
>>>>>>>>
>>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>>> unix domain socket and the Proxy protocol provided *most *of
>>>>>>>> the relevant/required information to tomcat. I believe we had
>>>>>>>> to add a Valve to tomcat to set the Remote IP however as the
>>>>>>>> patch didn't handle that case.
>>>>>>>>
>>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>>> getting a significant boost in throughput and decrease in
>>>>>>>> latency.
>>>>>>>>
>>>>>>>> +1 for this patch and willing to help out!
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>>> <Am...@veritas.com.invalid>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>>
>>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>>> attached in
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Cf200a998e3514a7fdba008dba7e2d4a5%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638288364940284915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jW2B%2BbjpdRSh3NW7%2BhgvcekqSDcXes7asGUabXbkjvU%3D&reserved=0 ?
>>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>>
>>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Amit
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in
>>>>>>>>> Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent)
>>>>>>>>>> TCP proxy e.g.
>>>>>>>>>>
>>>>>>>>> https://www/.
>>>>>>>>> envoyproxy.io
>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>>> c
>>>>>>>>> om
>>>>> %7Ca
>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6c
>>>>>>>>> a
>>>>>>>>> c
>>>>>>>>> 32%7C0
>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>>>> L
>>>>>>>>> j
>>>>>>>>> AwMDAi
>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>> &
>>>>>>>>> s
>>>>>>>>> data=W
>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>>> which supports the proxy protocol.
>>>>>>>>>>
>>>>>>>>>> Since there is not much action on this
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2
>>>>>>>>> F
>>>>>>>>> %25
>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eea
>>>>>>>>> c
>>>>>>>>> 1
>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C
>>>>>>>>> 0
>>>>>>>>> %
>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>> D
>>>>>>>>> A
>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>>>>>>>>> C
>>>>>>>>> &
>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=
>>>>>>>>> 0
>>>>>>>>> pache.org
>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c5
>>>>> 5
>>>>> b
>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb
>>>>> 3
>>>>> d
>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>> D
>>>>> %
>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfeh
>>>>> X v Q%3D&reserved=0, does it imply that most of the times Tomcat
>>>>> is running behind HTTP proxies and not TCP proxies?
>>>>>>>>>> Or does it mean that, Tomcat or applications running in
>>>>>>>>>> Tomcat does not
>>>>>>>>> need the remote client address information?
>>>>>>>>>
>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>>
>>>>>>>>> Hope that helps,
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>
>>>>>>>>>> Amit,
>>>>>>>>>>
>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>>> enhancement
>>>>>>>>> request.
>>>>>>>>>>>
>>>>>>>>>>> https://bz/.
>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4
>>>>>>>>>>> b
>>>>>>>>>>> 7
>>>>>>>>>>> 87206
>>>>>>>>>>> 08
>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381
>>>>>>>>>>> 9
>>>>>>>>>>> 3
>>>>>>>>>>> 50613
>>>>>>>>>>> 56
>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>>>>>>>>> l
>>>>>>>>>>> u
>>>>>>>>>>> MzIiL
>>>>>>>>>>> CJ
>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zg
>>>>>>>>>>> t
>>>>>>>>>>> L
>>>>>>>>>>> qUzY9
>>>>>>>>>>> JM
>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>>> pache.org
>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>>> P
>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e
>>>>>>>>>>> 1
>>>>>>>>>>> 3
>>>>>>>>>>> c0422
>>>>>>>>>>> c4
>>>>>>>>>>> c
>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7C
>>>>>>>>>>> T
>>>>>>>>>>> W
>>>>>>>>>>> FpbGZ
>>>>>>>>>>> sb
>>>>>>>>>>> 3
>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>>>>>>>>>> I
>>>>>>>>>>> 6
>>>>>>>>>>> Mn0%3
>>>>>>>>>>> D%
>>>>>>>>>>> 7
>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nO
>>>>>>>>>>> l
>>>>>>>>>>> 4
>>>>>>>>>>> mY%3D
>>>>>>>>>>> &r
>>>>>>>>>>> e
>>>>>>>>>>> served=0
>>>>>>>>>>>
>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>>> releases?
>>>>>>>>>>
>>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>>
>>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>>> it didn't
>>>>>>>>> look too difficult. It does require Tomcat to handle the
>>>>>>>>> stream directly and not just rely on Java's SSLServerSocket. I
>>>>>>>>> thought that had been done at some point, but it may not have.
>>>>>>>>> Handling the stream directly may have some other advantages as
>>>>>>>>> well, though it definitely makes the code more complicated.
>>>>>>>>>>
>>>>>>>>>>> Also, since this was requested long time back and there is
>>>>>>>>>>> no update, are there any other alternatives to pass the
>>>>>>>>>>> client information from load balancer to Tomcat in
>>>>>>>>>>> situations where there is no SSL termination at load balancer?
>>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>>> proxying
>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>>
>>>>>>>>>> -chris
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> -----
>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> -----
>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast,
>>>>>>>> see it as half full.
>>>>>>>> Engineers, of course, understand the glass is twice as big as
>>>>>>>> it needs to be.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> ---- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
28 Aug 2023 17:11:20 Amit Pande <Am...@veritas.com.INVALID>:
> Mark,
>
> Just checking - Did this issue get discussed in any of the core
> members' meeting?
There are no such meetings. Discussion happens on the mailing lists.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Amit Pande
> Sent: Monday, July 31, 2023 9:29 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Yes, understood.
>
> Thank you for clarifying. Even I was referring to initial consensus
> without any timeline or approach conclusion.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Mark Thomas <ma...@apache.org>
> Sent: Friday, July 28, 2023 2:48 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> On 28/07/2023 19:21, Amit Pande wrote:
>> Thank you all for the valuable discussion on this topic.
>>
>> Is it okay to say that we're agreeing to adding proxy protocol support
>> in Tomcat?
>
> I think that is a little too strong. At this point there is a proposed
> approach and no one is objecting but until there is an actual patch to
> discuss...
>
> Keep in mind that any committer can veto a change.
>
> My sense is that it should be possible to implement this feature while
> addressing any concerns that may be raised but it is not guaranteed.
>
> Mark
>
>
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Thursday, July 27, 2023 4:13 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> All,
>>
>> On 7/27/23 12:39, Mark Thomas wrote:
>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>>> On the topic of security, may we consider a trustedProxies setting?
>>>
>>> Seems reasonable.
>>
>> We should probably look at what httpd did for all of this.
>>
>> -chris
>>
>>>> This
>>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>>> It would need to be able to function with APR/NIO listening in a
>>>> Unix Domain Socket.
>>>>
>>>> I'm not sure if this is super useful, but the goal would be an added
>>>> layer of security to prevent Proxy Protocol header injection.
>>>>
>>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org>
>>>> wrote:
>>>>
>>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>>> Mark,
>>>>>>
>>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>>> supporting features backed by specifications rather than vendor
>>>>>>> specific hacks.
>>>>>>
>>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>>> nginx,
>>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>>> https://ww/
>>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients
>>>>> -
>>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
>>>>> a
>>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
>>>>> 6
>>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>>>>> 2
>>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa
>>>>> 0
>>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>>> ).
>>>>>
>>>>> ACK. That reduces my concerns somewhat.
>>>>>
>>>>>> Well, the reality is that people want to use this in the real
>>>>>> world and this is essentially the only way to do it, barring
>>>>>> coming up with a whole new protocol for the purpose (I'm looking
>>>>>> at /you/ AJP!).
>>>>>
>>>>> Indeed.
>>>>>
>>>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>>>> by every single product that currently supports this type of
>>>>>> thing?
>>>>>>
>>>>>>> My support for any patch is going to depend on the specifics of
>>>>>>> the patch.
>>>>>>>
>>>>>>> In addition to the comments in the BZ
>>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>>> other
>>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>>> RemoteIpFilter)
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> The whole point of PROXY is to kind of mix-together the
>>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>>> headers for
>>>>>> source-information) and the top-level idea of a Connector
>>>>>> (something that binds to a socket and pushes bytes around).
>>>>>>
>>>>>> The confusing thing here is that those two jobs are performed at
>>>>>> relatively different levels in Tomcat at the moment, as I
>>>>>> understand things.
>>>>>
>>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>>> higher level because that is where they sit but the data originates
>>>>> from the SocketWrapper.
>>>>>
>>>>>> If some kind of UberConnector could be built which essentially
>>>>>> does something like the following, it would be ideal:
>>>>>>
>>>>>> public void accept(Socket s) {
>>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>>
>>>>>> Connector realConnector = getRealConnector();
>>>>>>
>>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>>
>>>>>> realConnector.takeItAway(s);
>>>>>> }
>>>>>>
>>>>>> I'm sure there are other pieces of information that would be good
>>>>>> to pass-through, but the identity of the remote client is the most
>>>>>> interesting one.
>>>>>
>>>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>>>> the SocketWrapper rather than the Connector and to do it in a
>>>>> slightly different place. The Acceptor is too early as we want to
>>>>> do as little as possible on the Acceptor thread.
>>>>>
>>>>>>> - needs to be implemented for all Connectors
>>>>>>
>>>>>> I hope not. The connectors should be able to just have a thin
>>>>>> layer in front of them "sipping" the header off the beginning of
>>>>>> the connection.
>>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>>> works/should work", but conceptually it "seems easy". That may not
>>>>>> translate into "easy implementation" or it may mean "tons of
>>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>>
>>>>> My point was that the provided patch only implements this for NIO.
>>>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>>>> lot more difficult to implement and I'd be happy not implementing
>>>>> it for APR/Native.
>>>>>
>>>>>>> - I'd expect it to look more like the SNI processing
>>>>>>
>>>>>> SNI processing is very connector-dependent, of course, because
>>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC,
>>>>>> anything.
>>>>>> So if it can be implemented as something that can just "sit in
>>>>>> front of"
>>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>>> done separately and globally.
>>>>>
>>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>>
>>>>> SNI is handled independently of implementation and I think PROXY
>>>>> should be handled the same way. They also sit at almost the same
>>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>>> could be implemented within the existing handshake() method but I
>>>>> think it would be much cleaner in a separate method.
>>>>>
>>>>> Without looking at it too closely I think the implementation would
>>>>> look something like:
>>>>>
>>>>> - a new method on SocketWrapperBase that
>>>>> - checks if PROXY is enabled
>>>>> - returns immediately if PROXY is not enabled or has already
>>>>> been parsed
>>>>> - uses a new utility class (or classes) to parse the header
>>>>> (reading via the read() methods on SocketWrapperBase)
>>>>> - sets the cached values for remoteAddr, remoteHost,
>>>>> remotePort etc
>>>>> - The SocketProcessor.doRun() implementations add a call to this
>>>>> new
>>>>> method just before the TLS handshake
>>>>>
>>>>> If we want to support the TLS information then a little additional
>>>>> refactoring will be required (probably to cache the result of
>>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>>> insert a PROXY specific SSLSupport implementation.
>>>>>
>>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>>> Please don't hear me say "oh, this is easy, Mark... just go do
>>>>>> it!"
>>>>>> :)
>>>>>
>>>>> :)
>>>>>
>>>>> Actually with the patch that has already been provided and the
>>>>> suggested implementation outline above I don't think there is too
>>>>> much work to do.
>>>>>
>>>>>>> Generally, I don't think implementing this is going to be
>>>>>>> possible as some sort of plug-in.
>>>>>>
>>>>>> +1 Unless the plug-in is "a whole new set of
>>>>>> protocol/endpoint/etc.
>>>>>> handlers" which is a rather serious commitment.
>>>>>
>>>>> On reflection, with the approach above we probably could implement
>>>>> this via a new plug-in framework but I am not sure it is worth the
>>>>> effort at this point. Something to keep in mind if we have more
>>>>> things wanting to integrate at this point in the processing chain.
>>>>>
>>>>> Mark
>>>>>
>>>>>>
>>>>>> -chris
>>>>>>
>>>>>> [1]
>>>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
>>>>>> "haproxy"
>>>>>>
>>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>>> Missed to ask this:
>>>>>>>>
>>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>>> protocol
>>>>> support?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Amit Pande
>>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Chris, Mark,
>>>>>>>>
>>>>>>>> Any thoughts on this?
>>>>>>>>
>>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>>> any concerns (specially security wise)?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Just a side note, because we're also very interested in this
>>>>>>>> patch!
>>>>>>>>
>>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>>>> didn't handle that case.
>>>>>>>>
>>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>>> getting a significant boost in throughput and decrease in
>>>>>>>> latency.
>>>>>>>>
>>>>>>>> +1 for this patch and willing to help out!
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>>> <Am...@veritas.com.invalid>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>>
>>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>>> attached in
>>>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>>
>>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Amit
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>>>> proxy e.g.
>>>>>>>>>>
>>>>>>>>> https://www/.
>>>>>>>>> envoyproxy.io
>>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>>> c
>>>>>>>>> om
>>>>> %7Ca
>>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6ca
>>>>>>>>> c
>>>>>>>>> 32%7C0
>>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>>>>> j
>>>>>>>>> AwMDAi
>>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>>>> s
>>>>>>>>> data=W
>>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>>> which supports the proxy protocol.
>>>>>>>>>>
>>>>>>>>>> Since there is not much action on this
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F
>>>>>>>>> %25
>>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac
>>>>>>>>> 1
>>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0
>>>>>>>>> %
>>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>>> A
>>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>> &
>>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>>>> pache.org
>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55
>>>>> b
>>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3
>>>>> d
>>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>>>>> %
>>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehX
>>>>> v Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>>>> does not
>>>>>>>>> need the remote client address information?
>>>>>>>>>
>>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>>
>>>>>>>>> Hope that helps,
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>>
>>>>>>>>>> Amit,
>>>>>>>>>>
>>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>>> enhancement
>>>>>>>>> request.
>>>>>>>>>>>
>>>>>>>>>>> https://bz/.
>>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b
>>>>>>>>>>> 7
>>>>>>>>>>> 87206
>>>>>>>>>>> 08
>>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819
>>>>>>>>>>> 3
>>>>>>>>>>> 50613
>>>>>>>>>>> 56
>>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>>>>>>>>>>> u
>>>>>>>>>>> MzIiL
>>>>>>>>>>> CJ
>>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zgt
>>>>>>>>>>> L
>>>>>>>>>>> qUzY9
>>>>>>>>>>> JM
>>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>>> pache.org
>>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>>> P
>>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e1
>>>>>>>>>>> 3
>>>>>>>>>>> c0422
>>>>>>>>>>> c4
>>>>>>>>>>> c
>>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CT
>>>>>>>>>>> W
>>>>>>>>>>> FpbGZ
>>>>>>>>>>> sb
>>>>>>>>>>> 3
>>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>>>>>>> 6
>>>>>>>>>>> Mn0%3
>>>>>>>>>>> D%
>>>>>>>>>>> 7
>>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl
>>>>>>>>>>> 4
>>>>>>>>>>> mY%3D
>>>>>>>>>>> &r
>>>>>>>>>>> e
>>>>>>>>>>> served=0
>>>>>>>>>>>
>>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>>> releases?
>>>>>>>>>>
>>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>>
>>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>>> it didn't
>>>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>>>> the stream directly may have some other advantages as well,
>>>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>>>
>>>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>>> proxying
>>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>>
>>>>>>>>>> -chris
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -----
>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -----
>>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>>>> it as half full.
>>>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>>>> needs to be.
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> ---- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> -
>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Mark,
Just checking - Did this issue get discussed in any of the core members' meeting?
Thanks,
Amit
-----Original Message-----
From: Amit Pande
Sent: Monday, July 31, 2023 9:29 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
Yes, understood.
Thank you for clarifying. Even I was referring to initial consensus without any timeline or approach conclusion.
Thanks,
Amit
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
On 28/07/2023 19:21, Amit Pande wrote:
> Thank you all for the valuable discussion on this topic.
>
> Is it okay to say that we're agreeing to adding proxy protocol support in Tomcat?
I think that is a little too strong. At this point there is a proposed approach and no one is objecting but until there is an actual patch to discuss...
Keep in mind that any committer can veto a change.
My sense is that it should be possible to implement this feature while addressing any concerns that may be raised but it is not guaranteed.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Thursday, July 27, 2023 4:13 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> All,
>
> On 7/27/23 12:39, Mark Thomas wrote:
>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>> On the topic of security, may we consider a trustedProxies setting?
>>
>> Seems reasonable.
>
> We should probably look at what httpd did for all of this.
>
> -chris
>
>>> This
>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>> It would need to be able to function with APR/NIO listening in a
>>> Unix Domain Socket.
>>>
>>> I'm not sure if this is super useful, but the goal would be an added
>>> layer of security to prevent Proxy Protocol header injection.
>>>
>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>> Mark,
>>>>>
>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>> supporting features backed by specifications rather than vendor specific hacks.
>>>>>
>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>> nginx,
>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>> https://ww/
>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients
>>>> -
>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
>>>> a
>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
>>>> 6
>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>>>> 2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa
>>>> 0
>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>> ).
>>>>
>>>> ACK. That reduces my concerns somewhat.
>>>>
>>>>> Well, the reality is that people want to use this in the real
>>>>> world and this is essentially the only way to do it, barring
>>>>> coming up with a whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>>
>>>> Indeed.
>>>>
>>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>>> by every single product that currently supports this type of thing?
>>>>>
>>>>>> My support for any patch is going to depend on the specifics of
>>>>>> the patch.
>>>>>>
>>>>>> In addition to the comments in the BZ
>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>> other
>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>> RemoteIpFilter)
>>>>>
>>>>> +1
>>>>>
>>>>> The whole point of PROXY is to kind of mix-together the
>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>> headers for
>>>>> source-information) and the top-level idea of a Connector
>>>>> (something that binds to a socket and pushes bytes around).
>>>>>
>>>>> The confusing thing here is that those two jobs are performed at
>>>>> relatively different levels in Tomcat at the moment, as I
>>>>> understand things.
>>>>
>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>> higher level because that is where they sit but the data originates
>>>> from the SocketWrapper.
>>>>
>>>>> If some kind of UberConnector could be built which essentially
>>>>> does something like the following, it would be ideal:
>>>>>
>>>>> public void accept(Socket s) {
>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>
>>>>> Connector realConnector = getRealConnector();
>>>>>
>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>
>>>>> realConnector.takeItAway(s);
>>>>> }
>>>>>
>>>>> I'm sure there are other pieces of information that would be good
>>>>> to pass-through, but the identity of the remote client is the most
>>>>> interesting one.
>>>>
>>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>>> the SocketWrapper rather than the Connector and to do it in a
>>>> slightly different place. The Acceptor is too early as we want to
>>>> do as little as possible on the Acceptor thread.
>>>>
>>>>>> - needs to be implemented for all Connectors
>>>>>
>>>>> I hope not. The connectors should be able to just have a thin
>>>>> layer in front of them "sipping" the header off the beginning of the connection.
>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>> works/should work", but conceptually it "seems easy". That may not
>>>>> translate into "easy implementation" or it may mean "tons of
>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>
>>>> My point was that the provided patch only implements this for NIO.
>>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>>> lot more difficult to implement and I'd be happy not implementing
>>>> it for APR/Native.
>>>>
>>>>>> - I'd expect it to look more like the SNI processing
>>>>>
>>>>> SNI processing is very connector-dependent, of course, because
>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>>>> So if it can be implemented as something that can just "sit in
>>>>> front of"
>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>> done separately and globally.
>>>>
>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>
>>>> SNI is handled independently of implementation and I think PROXY
>>>> should be handled the same way. They also sit at almost the same
>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>> could be implemented within the existing handshake() method but I
>>>> think it would be much cleaner in a separate method.
>>>>
>>>> Without looking at it too closely I think the implementation would
>>>> look something like:
>>>>
>>>> - a new method on SocketWrapperBase that
>>>> - checks if PROXY is enabled
>>>> - returns immediately if PROXY is not enabled or has already
>>>> been parsed
>>>> - uses a new utility class (or classes) to parse the header
>>>> (reading via the read() methods on SocketWrapperBase)
>>>> - sets the cached values for remoteAddr, remoteHost,
>>>> remotePort etc
>>>> - The SocketProcessor.doRun() implementations add a call to this new
>>>> method just before the TLS handshake
>>>>
>>>> If we want to support the TLS information then a little additional
>>>> refactoring will be required (probably to cache the result of
>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>> insert a PROXY specific SSLSupport implementation.
>>>>
>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>> Please don't hear me say "oh, this is easy, Mark... just go do it!"
>>>>> :)
>>>>
>>>> :)
>>>>
>>>> Actually with the patch that has already been provided and the
>>>> suggested implementation outline above I don't think there is too much work to do.
>>>>
>>>>>> Generally, I don't think implementing this is going to be
>>>>>> possible as some sort of plug-in.
>>>>>
>>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>>> handlers" which is a rather serious commitment.
>>>>
>>>> On reflection, with the approach above we probably could implement
>>>> this via a new plug-in framework but I am not sure it is worth the
>>>> effort at this point. Something to keep in mind if we have more
>>>> things wanting to integrate at this point in the processing chain.
>>>>
>>>> Mark
>>>>
>>>>>
>>>>> -chris
>>>>>
>>>>> [1]
>>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for "haproxy"
>>>>>
>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>> Missed to ask this:
>>>>>>>
>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>> protocol
>>>> support?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Amit Pande
>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Chris, Mark,
>>>>>>>
>>>>>>> Any thoughts on this?
>>>>>>>
>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>> any concerns (specially security wise)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>>
>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>>> didn't handle that case.
>>>>>>>
>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>> getting a significant boost in throughput and decrease in latency.
>>>>>>>
>>>>>>> +1 for this patch and willing to help out!
>>>>>>>
>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>> <Am...@veritas.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>
>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>> attached in
>>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>
>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>>> proxy e.g.
>>>>>>>>>
>>>>>>>> https://www/.
>>>>>>>> envoyproxy.io
>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>> c
>>>>>>>> om
>>>> %7Ca
>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6ca
>>>>>>>> c
>>>>>>>> 32%7C0
>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>>>> j
>>>>>>>> AwMDAi
>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>>> s
>>>>>>>> data=W
>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>> which supports the proxy protocol.
>>>>>>>>>
>>>>>>>>> Since there is not much action on this
>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F
>>>>>>>> %25
>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac
>>>>>>>> 1
>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0
>>>>>>>> %
>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>> A
>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>> &
>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55
>>>> b
>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3
>>>> d
>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>>>> %
>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehX
>>>> v Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>>> does not
>>>>>>>> need the remote client address information?
>>>>>>>>
>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>> -chris
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>> enhancement
>>>>>>>> request.
>>>>>>>>>>
>>>>>>>>>> https://bz/.
>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b
>>>>>>>>>> 7
>>>>>>>>>> 87206
>>>>>>>>>> 08
>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819
>>>>>>>>>> 3
>>>>>>>>>> 50613
>>>>>>>>>> 56
>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>>>>>>>>>> u
>>>>>>>>>> MzIiL
>>>>>>>>>> CJ
>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zgt
>>>>>>>>>> L
>>>>>>>>>> qUzY9
>>>>>>>>>> JM
>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>> P
>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e1
>>>>>>>>>> 3
>>>>>>>>>> c0422
>>>>>>>>>> c4
>>>>>>>>>> c
>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CT
>>>>>>>>>> W
>>>>>>>>>> FpbGZ
>>>>>>>>>> sb
>>>>>>>>>> 3
>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>>>>>> 6
>>>>>>>>>> Mn0%3
>>>>>>>>>> D%
>>>>>>>>>> 7
>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl
>>>>>>>>>> 4
>>>>>>>>>> mY%3D
>>>>>>>>>> &r
>>>>>>>>>> e
>>>>>>>>>> served=0
>>>>>>>>>>
>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>> releases?
>>>>>>>>>
>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>
>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>> it didn't
>>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>>> the stream directly may have some other advantages as well,
>>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>>
>>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>> proxying
>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>>> it as half full.
>>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>>> needs to be.
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> ---- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Yes, understood.
Thank you for clarifying. Even I was referring to initial consensus without any timeline or approach conclusion.
Thanks,
Amit
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
On 28/07/2023 19:21, Amit Pande wrote:
> Thank you all for the valuable discussion on this topic.
>
> Is it okay to say that we're agreeing to adding proxy protocol support in Tomcat?
I think that is a little too strong. At this point there is a proposed approach and no one is objecting but until there is an actual patch to discuss...
Keep in mind that any committer can veto a change.
My sense is that it should be possible to implement this feature while addressing any concerns that may be raised but it is not guaranteed.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Thursday, July 27, 2023 4:13 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> All,
>
> On 7/27/23 12:39, Mark Thomas wrote:
>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>> On the topic of security, may we consider a trustedProxies setting?
>>
>> Seems reasonable.
>
> We should probably look at what httpd did for all of this.
>
> -chris
>
>>> This
>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>> It would need to be able to function with APR/NIO listening in a
>>> Unix Domain Socket.
>>>
>>> I'm not sure if this is super useful, but the goal would be an added
>>> layer of security to prevent Proxy Protocol header injection.
>>>
>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>> Mark,
>>>>>
>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>> I'm not a huge fan of this feature in general. I prefer
>>>>>> supporting features backed by specifications rather than vendor specific hacks.
>>>>>
>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>> nginx,
>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>> https://ww/
>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients
>>>> -
>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
>>>> a
>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
>>>> 6
>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>>>> 2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa
>>>> 0
>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>> ).
>>>>
>>>> ACK. That reduces my concerns somewhat.
>>>>
>>>>> Well, the reality is that people want to use this in the real
>>>>> world and this is essentially the only way to do it, barring
>>>>> coming up with a whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>>
>>>> Indeed.
>>>>
>>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>>> by every single product that currently supports this type of thing?
>>>>>
>>>>>> My support for any patch is going to depend on the specifics of
>>>>>> the patch.
>>>>>>
>>>>>> In addition to the comments in the BZ
>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>> other
>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>> RemoteIpFilter)
>>>>>
>>>>> +1
>>>>>
>>>>> The whole point of PROXY is to kind of mix-together the
>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>> headers for
>>>>> source-information) and the top-level idea of a Connector
>>>>> (something that binds to a socket and pushes bytes around).
>>>>>
>>>>> The confusing thing here is that those two jobs are performed at
>>>>> relatively different levels in Tomcat at the moment, as I
>>>>> understand things.
>>>>
>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>> higher level because that is where they sit but the data originates
>>>> from the SocketWrapper.
>>>>
>>>>> If some kind of UberConnector could be built which essentially
>>>>> does something like the following, it would be ideal:
>>>>>
>>>>> public void accept(Socket s) {
>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>
>>>>> Connector realConnector = getRealConnector();
>>>>>
>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>
>>>>> realConnector.takeItAway(s);
>>>>> }
>>>>>
>>>>> I'm sure there are other pieces of information that would be good
>>>>> to pass-through, but the identity of the remote client is the most
>>>>> interesting one.
>>>>
>>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>>> the SocketWrapper rather than the Connector and to do it in a
>>>> slightly different place. The Acceptor is too early as we want to
>>>> do as little as possible on the Acceptor thread.
>>>>
>>>>>> - needs to be implemented for all Connectors
>>>>>
>>>>> I hope not. The connectors should be able to just have a thin
>>>>> layer in front of them "sipping" the header off the beginning of the connection.
>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>> works/should work", but conceptually it "seems easy". That may not
>>>>> translate into "easy implementation" or it may mean "tons of
>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>
>>>> My point was that the provided patch only implements this for NIO.
>>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>>> lot more difficult to implement and I'd be happy not implementing
>>>> it for APR/Native.
>>>>
>>>>>> - I'd expect it to look more like the SNI processing
>>>>>
>>>>> SNI processing is very connector-dependent, of course, because
>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>>>> So if it can be implemented as something that can just "sit in
>>>>> front of"
>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>> done separately and globally.
>>>>
>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>
>>>> SNI is handled independently of implementation and I think PROXY
>>>> should be handled the same way. They also sit at almost the same
>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>> could be implemented within the existing handshake() method but I
>>>> think it would be much cleaner in a separate method.
>>>>
>>>> Without looking at it too closely I think the implementation would
>>>> look something like:
>>>>
>>>> - a new method on SocketWrapperBase that
>>>> - checks if PROXY is enabled
>>>> - returns immediately if PROXY is not enabled or has already
>>>> been parsed
>>>> - uses a new utility class (or classes) to parse the header
>>>> (reading via the read() methods on SocketWrapperBase)
>>>> - sets the cached values for remoteAddr, remoteHost,
>>>> remotePort etc
>>>> - The SocketProcessor.doRun() implementations add a call to this new
>>>> method just before the TLS handshake
>>>>
>>>> If we want to support the TLS information then a little additional
>>>> refactoring will be required (probably to cache the result of
>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>> insert a PROXY specific SSLSupport implementation.
>>>>
>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>> Please don't hear me say "oh, this is easy, Mark... just go do it!"
>>>>> :)
>>>>
>>>> :)
>>>>
>>>> Actually with the patch that has already been provided and the
>>>> suggested implementation outline above I don't think there is too much work to do.
>>>>
>>>>>> Generally, I don't think implementing this is going to be
>>>>>> possible as some sort of plug-in.
>>>>>
>>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>>> handlers" which is a rather serious commitment.
>>>>
>>>> On reflection, with the approach above we probably could implement
>>>> this via a new plug-in framework but I am not sure it is worth the
>>>> effort at this point. Something to keep in mind if we have more
>>>> things wanting to integrate at this point in the processing chain.
>>>>
>>>> Mark
>>>>
>>>>>
>>>>> -chris
>>>>>
>>>>> [1]
>>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for "haproxy"
>>>>>
>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>> Missed to ask this:
>>>>>>>
>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>> protocol
>>>> support?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Amit Pande
>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Chris, Mark,
>>>>>>>
>>>>>>> Any thoughts on this?
>>>>>>>
>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>> any concerns (specially security wise)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>>
>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>>> didn't handle that case.
>>>>>>>
>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>> getting a significant boost in throughput and decrease in latency.
>>>>>>>
>>>>>>> +1 for this patch and willing to help out!
>>>>>>>
>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>> <Am...@veritas.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>
>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>> attached in
>>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>
>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>>> proxy e.g.
>>>>>>>>>
>>>>>>>> https://www/.
>>>>>>>> envoyproxy.io
>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>> c
>>>>>>>> om
>>>> %7Ca
>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6ca
>>>>>>>> c
>>>>>>>> 32%7C0
>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>>>> j
>>>>>>>> AwMDAi
>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>>> s
>>>>>>>> data=W
>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>> which supports the proxy protocol.
>>>>>>>>>
>>>>>>>>> Since there is not much action on this
>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F
>>>>>>>> %25
>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac
>>>>>>>> 1
>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0
>>>>>>>> %
>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>> A
>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>> &
>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55
>>>> b
>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3
>>>> d
>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>>>> %
>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehX
>>>> v Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>>> does not
>>>>>>>> need the remote client address information?
>>>>>>>>
>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>> -chris
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>> enhancement
>>>>>>>> request.
>>>>>>>>>>
>>>>>>>>>> https://bz/.
>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b
>>>>>>>>>> 7
>>>>>>>>>> 87206
>>>>>>>>>> 08
>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819
>>>>>>>>>> 3
>>>>>>>>>> 50613
>>>>>>>>>> 56
>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>>>>>>>>>> u
>>>>>>>>>> MzIiL
>>>>>>>>>> CJ
>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zgt
>>>>>>>>>> L
>>>>>>>>>> qUzY9
>>>>>>>>>> JM
>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>> P
>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e1
>>>>>>>>>> 3
>>>>>>>>>> c0422
>>>>>>>>>> c4
>>>>>>>>>> c
>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CT
>>>>>>>>>> W
>>>>>>>>>> FpbGZ
>>>>>>>>>> sb
>>>>>>>>>> 3
>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>>>>>> 6
>>>>>>>>>> Mn0%3
>>>>>>>>>> D%
>>>>>>>>>> 7
>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl
>>>>>>>>>> 4
>>>>>>>>>> mY%3D
>>>>>>>>>> &r
>>>>>>>>>> e
>>>>>>>>>> served=0
>>>>>>>>>>
>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>> releases?
>>>>>>>>>
>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>
>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>> it didn't
>>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>>> the stream directly may have some other advantages as well,
>>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>>
>>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>> proxying
>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>>> it as half full.
>>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>>> needs to be.
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> ---- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 28/07/2023 19:21, Amit Pande wrote:
> Thank you all for the valuable discussion on this topic.
>
> Is it okay to say that we're agreeing to adding proxy protocol support in Tomcat?
I think that is a little too strong. At this point there is a proposed
approach and no one is objecting but until there is an actual patch to
discuss...
Keep in mind that any committer can veto a change.
My sense is that it should be possible to implement this feature while
addressing any concerns that may be raised but it is not guaranteed.
Mark
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Thursday, July 27, 2023 4:13 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> All,
>
> On 7/27/23 12:39, Mark Thomas wrote:
>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>> On the topic of security, may we consider a trustedProxies setting?
>>
>> Seems reasonable.
>
> We should probably look at what httpd did for all of this.
>
> -chris
>
>>> This
>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>> It would need to be able to function with APR/NIO listening in a Unix
>>> Domain Socket.
>>>
>>> I'm not sure if this is super useful, but the goal would be an added
>>> layer of security to prevent Proxy Protocol header injection.
>>>
>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>>> Mark,
>>>>>
>>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>>> I'm not a huge fan of this feature in general. I prefer supporting
>>>>>> features backed by specifications rather than vendor specific hacks.
>>>>>
>>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>>> backed by an RFC. It's published by haproxy, but supported by
>>>>> nginx,
>>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>>> https://ww/
>>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients-
>>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14fa
>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63826
>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa0
>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>>> ).
>>>>
>>>> ACK. That reduces my concerns somewhat.
>>>>
>>>>> Well, the reality is that people want to use this in the real world
>>>>> and this is essentially the only way to do it, barring coming up
>>>>> with a whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>>
>>>> Indeed.
>>>>
>>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>>> by every single product that currently supports this type of thing?
>>>>>
>>>>>> My support for any patch is going to depend on the specifics of
>>>>>> the patch.
>>>>>>
>>>>>> In addition to the comments in the BZ
>>>>>> - exposing the data as a request attribute is inconsistent with
>>>>>> other
>>>>>> mechanisms that solve the same problem (e.g. see
>>>>>> RemoteIpFilter)
>>>>>
>>>>> +1
>>>>>
>>>>> The whole point of PROXY is to kind of mix-together the
>>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>>> headers for
>>>>> source-information) and the top-level idea of a Connector
>>>>> (something that binds to a socket and pushes bytes around).
>>>>>
>>>>> The confusing thing here is that those two jobs are performed at
>>>>> relatively different levels in Tomcat at the moment, as I
>>>>> understand things.
>>>>
>>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>>> higher level because that is where they sit but the data originates
>>>> from the SocketWrapper.
>>>>
>>>>> If some kind of UberConnector could be built which essentially does
>>>>> something like the following, it would be ideal:
>>>>>
>>>>> public void accept(Socket s) {
>>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>>
>>>>> Connector realConnector = getRealConnector();
>>>>>
>>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>>
>>>>> realConnector.takeItAway(s);
>>>>> }
>>>>>
>>>>> I'm sure there are other pieces of information that would be good
>>>>> to pass-through, but the identity of the remote client is the most
>>>>> interesting one.
>>>>
>>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>>> the SocketWrapper rather than the Connector and to do it in a
>>>> slightly different place. The Acceptor is too early as we want to do
>>>> as little as possible on the Acceptor thread.
>>>>
>>>>>> - needs to be implemented for all Connectors
>>>>>
>>>>> I hope not. The connectors should be able to just have a thin layer
>>>>> in front of them "sipping" the header off the beginning of the connection.
>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>> works/should work", but conceptually it "seems easy". That may not
>>>>> translate into "easy implementation" or it may mean "tons of
>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>
>>>> My point was that the provided patch only implements this for NIO.
>>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>>> lot more difficult to implement and I'd be happy not implementing it
>>>> for APR/Native.
>>>>
>>>>>> - I'd expect it to look more like the SNI processing
>>>>>
>>>>> SNI processing is very connector-dependent, of course, because it's
>>>>> HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>>>> So if it can be implemented as something that can just "sit in
>>>>> front of"
>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>> done separately and globally.
>>>>
>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>
>>>> SNI is handled independently of implementation and I think PROXY
>>>> should be handled the same way. They also sit at almost the same
>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>> could be implemented within the existing handshake() method but I
>>>> think it would be much cleaner in a separate method.
>>>>
>>>> Without looking at it too closely I think the implementation would
>>>> look something like:
>>>>
>>>> - a new method on SocketWrapperBase that
>>>> - checks if PROXY is enabled
>>>> - returns immediately if PROXY is not enabled or has already
>>>> been parsed
>>>> - uses a new utility class (or classes) to parse the header
>>>> (reading via the read() methods on SocketWrapperBase)
>>>> - sets the cached values for remoteAddr, remoteHost,
>>>> remotePort etc
>>>> - The SocketProcessor.doRun() implementations add a call to this new
>>>> method just before the TLS handshake
>>>>
>>>> If we want to support the TLS information then a little additional
>>>> refactoring will be required (probably to cache the result of
>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>> insert a PROXY specific SSLSupport implementation.
>>>>
>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>> Please don't hear me say "oh, this is easy, Mark... just go do it!"
>>>>> :)
>>>>
>>>> :)
>>>>
>>>> Actually with the patch that has already been provided and the
>>>> suggested implementation outline above I don't think there is too much work to do.
>>>>
>>>>>> Generally, I don't think implementing this is going to be possible
>>>>>> as some sort of plug-in.
>>>>>
>>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>>> handlers" which is a rather serious commitment.
>>>>
>>>> On reflection, with the approach above we probably could implement
>>>> this via a new plug-in framework but I am not sure it is worth the
>>>> effort at this point. Something to keep in mind if we have more
>>>> things wanting to integrate at this point in the processing chain.
>>>>
>>>> Mark
>>>>
>>>>>
>>>>> -chris
>>>>>
>>>>> [1]
>>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for "haproxy"
>>>>>
>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>> Missed to ask this:
>>>>>>>
>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>> protocol
>>>> support?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Amit Pande
>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Chris, Mark,
>>>>>>>
>>>>>>> Any thoughts on this?
>>>>>>>
>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>> any concerns (specially security wise)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>>
>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>>> didn't handle that case.
>>>>>>>
>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>> getting a significant boost in throughput and decrease in latency.
>>>>>>>
>>>>>>> +1 for this patch and willing to help out!
>>>>>>>
>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>> <Am...@veritas.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>
>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>> attached in
>>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>
>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>>> proxy e.g.
>>>>>>>>>
>>>>>>>> https://www/.
>>>>>>>> envoyproxy.io
>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.c
>>>>>>>> om
>>>> %7Ca
>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac
>>>>>>>> 32%7C0
>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>>>>> AwMDAi
>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>>>>>>> data=W
>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>> which supports the proxy protocol.
>>>>>>>>>
>>>>>>>>> Since there is not much action on this
>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%25
>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac1
>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%
>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b
>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d
>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXv
>>>> Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>>> does not
>>>>>>>> need the remote client address information?
>>>>>>>>
>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>> multiple services behind my reverse-proxy which run in different
>>>>>>>> places. It's not just s dumb pass-through.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>> -chris
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>> enhancement
>>>>>>>> request.
>>>>>>>>>>
>>>>>>>>>> https://bz/.
>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b7
>>>>>>>>>> 87206
>>>>>>>>>> 08
>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638193
>>>>>>>>>> 50613
>>>>>>>>>> 56
>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>>>>>>>>>> MzIiL
>>>>>>>>>> CJ
>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtL
>>>>>>>>>> qUzY9
>>>>>>>>>> JM
>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>> P
>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13
>>>>>>>>>> c0422
>>>>>>>>>> c4
>>>>>>>>>> c
>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTW
>>>>>>>>>> FpbGZ
>>>>>>>>>> sb
>>>>>>>>>> 3
>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>>>>>> Mn0%3
>>>>>>>>>> D%
>>>>>>>>>> 7
>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4
>>>>>>>>>> mY%3D
>>>>>>>>>> &r
>>>>>>>>>> e
>>>>>>>>>> served=0
>>>>>>>>>>
>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>> releases?
>>>>>>>>>
>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>
>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>> it didn't
>>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>>> the stream directly may have some other advantages as well,
>>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>>
>>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>> proxying
>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>
>>>>>>>>> -chris
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -----
>>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jonathan | exabrial@gmail.com
>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>>> it as half full.
>>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>>> needs to be.
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ---- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Thank you all for the valuable discussion on this topic.
Is it okay to say that we're agreeing to adding proxy protocol support in Tomcat?
Thanks,
Amit
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, July 27, 2023 4:13 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
All,
On 7/27/23 12:39, Mark Thomas wrote:
> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>> On the topic of security, may we consider a trustedProxies setting?
>
> Seems reasonable.
We should probably look at what httpd did for all of this.
-chris
>> This
>> would be an analog to the internalProxies setting on RemoteIpValve.
>> It would need to be able to function with APR/NIO listening in a Unix
>> Domain Socket.
>>
>> I'm not sure if this is super useful, but the goal would be an added
>> layer of security to prevent Proxy Protocol header injection.
>>
>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>>
>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>> Mark,
>>>>
>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>> I'm not a huge fan of this feature in general. I prefer supporting
>>>>> features backed by specifications rather than vendor specific hacks.
>>>>
>>>> I think the PROXY protocol is fairly standard, even if it's not
>>>> backed by an RFC. It's published by haproxy, but supported by
>>>> nginx,
>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
>>> https://ww/
>>> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients-
>>> ip-address&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14fa
>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63826
>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa0
>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=0
>>> ).
>>>
>>> ACK. That reduces my concerns somewhat.
>>>
>>>> Well, the reality is that people want to use this in the real world
>>>> and this is essentially the only way to do it, barring coming up
>>>> with a whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>
>>> Indeed.
>>>
>>>> So why not use /the/ protocol that (a) exists and (b) is supported
>>>> by every single product that currently supports this type of thing?
>>>>
>>>>> My support for any patch is going to depend on the specifics of
>>>>> the patch.
>>>>>
>>>>> In addition to the comments in the BZ
>>>>> - exposing the data as a request attribute is inconsistent with
>>>>> other
>>>>> mechanisms that solve the same problem (e.g. see
>>>>> RemoteIpFilter)
>>>>
>>>> +1
>>>>
>>>> The whole point of PROXY is to kind of mix-together the
>>>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
>>>> headers for
>>>> source-information) and the top-level idea of a Connector
>>>> (something that binds to a socket and pushes bytes around).
>>>>
>>>> The confusing thing here is that those two jobs are performed at
>>>> relatively different levels in Tomcat at the moment, as I
>>>> understand things.
>>>
>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
>>> higher level because that is where they sit but the data originates
>>> from the SocketWrapper.
>>>
>>>> If some kind of UberConnector could be built which essentially does
>>>> something like the following, it would be ideal:
>>>>
>>>> public void accept(Socket s) {
>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>
>>>> Connector realConnector = getRealConnector();
>>>>
>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>
>>>> realConnector.takeItAway(s);
>>>> }
>>>>
>>>> I'm sure there are other pieces of information that would be good
>>>> to pass-through, but the identity of the remote client is the most
>>>> interesting one.
>>>
>>> Yes, that is the general idea. Just a couple of minor tweaks to use
>>> the SocketWrapper rather than the Connector and to do it in a
>>> slightly different place. The Acceptor is too early as we want to do
>>> as little as possible on the Acceptor thread.
>>>
>>>>> - needs to be implemented for all Connectors
>>>>
>>>> I hope not. The connectors should be able to just have a thin layer
>>>> in front of them "sipping" the header off the beginning of the connection.
>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>> works/should work", but conceptually it "seems easy". That may not
>>>> translate into "easy implementation" or it may mean "tons of
>>>> refactoring that we wouldn't need if we didn't care that much."
>>>
>>> My point was that the provided patch only implements this for NIO.
>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>> lot more difficult to implement and I'd be happy not implementing it
>>> for APR/Native.
>>>
>>>>> - I'd expect it to look more like the SNI processing
>>>>
>>>> SNI processing is very connector-dependent, of course, because it's
>>>> HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>>> So if it can be implemented as something that can just "sit in
>>>> front of"
>>>> *any* connector now or in the future of Tomcat, that would be
>>>> ideal. It could definitely be implemented as an "optional feature"
>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>> done separately and globally.
>>>
>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>
>>> SNI is handled independently of implementation and I think PROXY
>>> should be handled the same way. They also sit at almost the same
>>> point in the processing (PROXY needs to be first). PROXY parsing
>>> could be implemented within the existing handshake() method but I
>>> think it would be much cleaner in a separate method.
>>>
>>> Without looking at it too closely I think the implementation would
>>> look something like:
>>>
>>> - a new method on SocketWrapperBase that
>>> - checks if PROXY is enabled
>>> - returns immediately if PROXY is not enabled or has already
>>> been parsed
>>> - uses a new utility class (or classes) to parse the header
>>> (reading via the read() methods on SocketWrapperBase)
>>> - sets the cached values for remoteAddr, remoteHost,
>>> remotePort etc
>>> - The SocketProcessor.doRun() implementations add a call to this new
>>> method just before the TLS handshake
>>>
>>> If we want to support the TLS information then a little additional
>>> refactoring will be required (probably to cache the result of
>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>> insert a PROXY specific SSLSupport implementation.
>>>
>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>> Please don't hear me say "oh, this is easy, Mark... just go do it!"
>>>> :)
>>>
>>> :)
>>>
>>> Actually with the patch that has already been provided and the
>>> suggested implementation outline above I don't think there is too much work to do.
>>>
>>>>> Generally, I don't think implementing this is going to be possible
>>>>> as some sort of plug-in.
>>>>
>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>> handlers" which is a rather serious commitment.
>>>
>>> On reflection, with the approach above we probably could implement
>>> this via a new plug-in framework but I am not sure it is worth the
>>> effort at this point. Something to keep in mind if we have more
>>> things wanting to integrate at this point in the processing chain.
>>>
>>> Mark
>>>
>>>>
>>>> -chris
>>>>
>>>> [1]
>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for "haproxy"
>>>>
>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>> Missed to ask this:
>>>>>>
>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>> protocol
>>> support?
>>>>>>
>>>>>> Thanks,
>>>>>> Amit
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Amit Pande
>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>
>>>>>> Chris, Mark,
>>>>>>
>>>>>> Any thoughts on this?
>>>>>>
>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>> any concerns (specially security wise)?
>>>>>>
>>>>>> Thanks,
>>>>>> Amit
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>
>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>
>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>> didn't handle that case.
>>>>>>
>>>>>> I can find my notes from that experiment, but I do remember
>>>>>> getting a significant boost in throughput and decrease in latency.
>>>>>>
>>>>>> +1 for this patch and willing to help out!
>>>>>>
>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>> <Am...@veritas.com.invalid>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you, Chris, again for inputs.
>>>>>>> And sorry to circle back on this, late.
>>>>>>>
>>>>>>> One related question is - does it make sense to use the patch
>>>>>>> attached in
>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>
>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>> looks like there are some more points to be concluded.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Amit,
>>>>>>>
>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>> proxy e.g.
>>>>>>>>
>>>>>>> https://www/.
>>>>>>> envoyproxy.io
>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.c
>>>>>>> om
>>> %7Ca
>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac
>>>>>>> 32%7C0
>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>>>> AwMDAi
>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>>>>>> data=W
>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>> which supports the proxy protocol.
>>>>>>>>
>>>>>>>> Since there is not much action on this
>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%25
>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac1
>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%
>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>> pache.org
>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b
>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d
>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXv
>>> Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>> does not
>>>>>>> need the remote client address information?
>>>>>>>
>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>> multiple services behind my reverse-proxy which run in different
>>>>>>> places. It's not just s dumb pass-through.
>>>>>>>
>>>>>>> Hope that helps,
>>>>>>> -chris
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>> enhancement
>>>>>>> request.
>>>>>>>>>
>>>>>>>>> https://bz/.
>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b7
>>>>>>>>> 87206
>>>>>>>>> 08
>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638193
>>>>>>>>> 50613
>>>>>>>>> 56
>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>>>>>>>>> MzIiL
>>>>>>>>> CJ
>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtL
>>>>>>>>> qUzY9
>>>>>>>>> JM
>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>> pache.org
>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>> P
>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13
>>>>>>>>> c0422
>>>>>>>>> c4
>>>>>>>>> c
>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTW
>>>>>>>>> FpbGZ
>>>>>>>>> sb
>>>>>>>>> 3
>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>>>>> Mn0%3
>>>>>>>>> D%
>>>>>>>>> 7
>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4
>>>>>>>>> mY%3D
>>>>>>>>> &r
>>>>>>>>> e
>>>>>>>>> served=0
>>>>>>>>>
>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>> releases?
>>>>>>>>
>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>
>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>> it didn't
>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>> the stream directly may have some other advantages as well,
>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>
>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>> proxying
>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>> really is the best way to do that, honestly.
>>>>>>>>
>>>>>>>> -chris
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -----
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -----
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> ----- To unsubscribe, e-mail:
>>>>>>> users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jonathan | exabrial@gmail.com
>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>> it as half full.
>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>> needs to be.
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ---- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 7/27/23 12:39, Mark Thomas wrote:
> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>> On the topic of security, may we consider a trustedProxies setting?
>
> Seems reasonable.
We should probably look at what httpd did for all of this.
-chris
>> This
>> would be an analog to the internalProxies setting on RemoteIpValve. It
>> would need to be able to function with APR/NIO listening in a Unix Domain
>> Socket.
>>
>> I'm not sure if this is super useful, but the goal would be an added
>> layer
>> of security to prevent Proxy Protocol header injection.
>>
>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>>
>>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>>> Mark,
>>>>
>>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>>> I'm not a huge fan of this feature in general. I prefer supporting
>>>>> features backed by specifications rather than vendor specific hacks.
>>>>
>>>> I think the PROXY protocol is fairly standard, even if it's not backed
>>>> by an RFC. It's published by haproxy, but supported by nginx,
>>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others
>>>> (
>>> https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address
>>> ).
>>>
>>> ACK. That reduces my concerns somewhat.
>>>
>>>> Well, the reality is that people want to use this in the real world and
>>>> this is essentially the only way to do it, barring coming up with a
>>>> whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>>
>>> Indeed.
>>>
>>>> So why not use /the/ protocol that (a) exists and (b) is supported by
>>>> every single product that currently supports this type of thing?
>>>>
>>>>> My support for any patch is going to depend on the specifics of the
>>>>> patch.
>>>>>
>>>>> In addition to the comments in the BZ
>>>>> - exposing the data as a request attribute is inconsistent with other
>>>>> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
>>>>
>>>> +1
>>>>
>>>> The whole point of PROXY is to kind of mix-together the capabilities of
>>>> both the RemoteIPFilter/Valve (which uses HTTP headers for
>>>> source-information) and the top-level idea of a Connector (something
>>>> that binds to a socket and pushes bytes around).
>>>>
>>>> The confusing thing here is that those two jobs are performed at
>>>> relatively different levels in Tomcat at the moment, as I understand
>>>> things.
>>>
>>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a higher
>>> level because that is where they sit but the data originates from the
>>> SocketWrapper.
>>>
>>>> If some kind of UberConnector could be built which essentially does
>>>> something like the following, it would be ideal:
>>>>
>>>> public void accept(Socket s) {
>>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>>
>>>> Connector realConnector = getRealConnector();
>>>>
>>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>>
>>>> realConnector.takeItAway(s);
>>>> }
>>>>
>>>> I'm sure there are other pieces of information that would be good to
>>>> pass-through, but the identity of the remote client is the most
>>>> interesting one.
>>>
>>> Yes, that is the general idea. Just a couple of minor tweaks to use the
>>> SocketWrapper rather than the Connector and to do it in a slightly
>>> different place. The Acceptor is too early as we want to do as little as
>>> possible on the Acceptor thread.
>>>
>>>>> - needs to be implemented for all Connectors
>>>>
>>>> I hope not. The connectors should be able to just have a thin layer in
>>>> front of them "sipping" the header off the beginning of the connection.
>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>> and so
>>>> I don't want to appear to be telling you (Mark) "how it works/should
>>>> work", but conceptually it "seems easy". That may not translate into
>>>> "easy implementation" or it may mean "tons of refactoring that we
>>>> wouldn't need if we didn't care that much."
>>>
>>> My point was that the provided patch only implements this for NIO. It
>>> needs to implement it for NIO2 as well. APR/Native looks to be a lot
>>> more difficult to implement and I'd be happy not implementing it for
>>> APR/Native.
>>>
>>>>> - I'd expect it to look more like the SNI processing
>>>>
>>>> SNI processing is very connector-dependent, of course, because it's
>>>> HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>>> So if it can be implemented as something that can just "sit in front
>>>> of"
>>>> *any* connector now or in the future of Tomcat, that would be ideal. It
>>>> could definitely be implemented as an "optional feature" on a
>>>> Connector-by-Connector basis, but my sense is that it can be done
>>>> separately and globally.
>>>
>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc) whereas I
>>> am thinking in terms of implementation (NIO, NIO2, etc).
>>>
>>> SNI is handled independently of implementation and I think PROXY should
>>> be handled the same way. They also sit at almost the same point in the
>>> processing (PROXY needs to be first). PROXY parsing could be implemented
>>> within the existing handshake() method but I think it would be much
>>> cleaner in a separate method.
>>>
>>> Without looking at it too closely I think the implementation would look
>>> something like:
>>>
>>> - a new method on SocketWrapperBase that
>>> - checks if PROXY is enabled
>>> - returns immediately if PROXY is not enabled or has already
>>> been parsed
>>> - uses a new utility class (or classes) to parse the header
>>> (reading via the read() methods on SocketWrapperBase)
>>> - sets the cached values for remoteAddr, remoteHost,
>>> remotePort etc
>>> - The SocketProcessor.doRun() implementations add a call to this new
>>> method just before the TLS handshake
>>>
>>> If we want to support the TLS information then a little additional
>>> refactoring will be required (probably to cache the result of
>>> SocketWrapperBase.getSslSupport) so the new utility classes can insert a
>>> PROXY specific SSLSupport implementation.
>>>
>>>> Again, I'm speaking from a position of profound ignorance, here. Please
>>>> don't hear me say "oh, this is easy, Mark... just go do it!" :)
>>>
>>> :)
>>>
>>> Actually with the patch that has already been provided and the suggested
>>> implementation outline above I don't think there is too much work to do.
>>>
>>>>> Generally, I don't think implementing this is going to be possible as
>>>>> some sort of plug-in.
>>>>
>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>> handlers" which is a rather serious commitment.
>>>
>>> On reflection, with the approach above we probably could implement this
>>> via a new plug-in framework but I am not sure it is worth the effort at
>>> this point. Something to keep in mind if we have more things wanting to
>>> integrate at this point in the processing chain.
>>>
>>> Mark
>>>
>>>>
>>>> -chris
>>>>
>>>> [1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
>>>> "haproxy"
>>>>
>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>> Missed to ask this:
>>>>>>
>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>> Was wondering if it would be possible to refactor this patch and/or
>>>>>> allow Tomcat core code to extend and plug-in the proxy protocol
>>> support?
>>>>>>
>>>>>> Thanks,
>>>>>> Amit
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Amit Pande
>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>
>>>>>> Chris, Mark,
>>>>>>
>>>>>> Any thoughts on this?
>>>>>>
>>>>>> Mark, if we clean up the patch and re-submit, do you will have any
>>>>>> concerns (specially security wise)?
>>>>>>
>>>>>> Thanks,
>>>>>> Amit
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>
>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>
>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix
>>>>>> domain socket and the Proxy protocol provided *most *of the
>>>>>> relevant/required information to tomcat. I believe we had to add a
>>>>>> Valve to tomcat to set the Remote IP however as the patch didn't
>>>>>> handle that case.
>>>>>>
>>>>>> I can find my notes from that experiment, but I do remember getting a
>>>>>> significant boost in throughput and decrease in latency.
>>>>>>
>>>>>> +1 for this patch and willing to help out!
>>>>>>
>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>> <Am...@veritas.com.invalid>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you, Chris, again for inputs.
>>>>>>> And sorry to circle back on this, late.
>>>>>>>
>>>>>>> One related question is - does it make sense to use the patch
>>>>>>> attached
>>>>>>> in
>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>
>>>>>>> There are concerns from Mark about using the patch in its current
>>>>>>> state, but I see last comment (#24) on the issue and looks like
>>>>>>> there
>>>>>>> are some more points to be concluded.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Amit,
>>>>>>>
>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>> proxy e.g.
>>>>>>>>
>>>>>>> https://www/.
>>>>>>> envoyproxy.io
>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com
>>> %7Ca
>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>> which supports the proxy protocol.
>>>>>>>>
>>>>>>>> Since there is not much action on this
>>>>>>> https://bz.a/
>>>>>>> pache.org
>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0,
>>> does it imply that most of the times Tomcat is running behind HTTP
>>> proxies
>>> and not TCP proxies?
>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat does
>>>>>>>> not
>>>>>>> need the remote client address information?
>>>>>>>
>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>> wouldn't
>>>>>>> be able to use a TCP load-balancer because I hide multiple services
>>>>>>> behind my reverse-proxy which run in different places. It's not just
>>>>>>> s dumb pass-through.
>>>>>>>
>>>>>>> Hope that helps,
>>>>>>> -chris
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>> enhancement
>>>>>>> request.
>>>>>>>>>
>>>>>>>>> https://bz/.
>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
>>>>>>>>> 08
>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
>>>>>>>>> 56
>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>>>>>> CJ
>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
>>>>>>>>> JM
>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>> pache.org
>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>> P
>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
>>>>>>>>> c4
>>>>>>>>> c
>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
>>>>>>>>> sb
>>>>>>>>> 3
>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>>> D%
>>>>>>>>> 7
>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
>>>>>>>>> &r
>>>>>>>>> e
>>>>>>>>> served=0
>>>>>>>>>
>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>> releases?
>>>>>>>>
>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>
>>>>>>>> I thought that markt had looked at this a while back and said it
>>>>>>>> didn't
>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought that
>>>>>>> had been done at some point, but it may not have. Handling the
>>>>>>> stream
>>>>>>> directly may have some other advantages as well, though it
>>>>>>> definitely
>>>>>>> makes the code more complicated.
>>>>>>>>
>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>> information from load balancer to Tomcat in situations where there
>>>>>>>>> is no SSL termination at load balancer?
>>>>>>>> You mean like a network load balancer where the lb is just proxying
>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>> really is
>>>>>>> the best way to do that, honestly.
>>>>>>>>
>>>>>>>> -chris
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jonathan | exabrial@gmail.com
>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see it
>>>>>> as half full.
>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>> needs to be.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 27/07/2023 16:27, Jonathan S. Fisher wrote:
> On the topic of security, may we consider a trustedProxies setting?
Seems reasonable.
Mark
> This
> would be an analog to the internalProxies setting on RemoteIpValve. It
> would need to be able to function with APR/NIO listening in a Unix Domain
> Socket.
>
> I'm not sure if this is super useful, but the goal would be an added layer
> of security to prevent Proxy Protocol header injection.
>
> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
>
>> On 26/07/2023 21:53, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 7/26/23 13:58, Mark Thomas wrote:
>>>> I'm not a huge fan of this feature in general. I prefer supporting
>>>> features backed by specifications rather than vendor specific hacks.
>>>
>>> I think the PROXY protocol is fairly standard, even if it's not backed
>>> by an RFC. It's published by haproxy, but supported by nginx,
>>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others
>>> (
>> https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address
>> ).
>>
>> ACK. That reduces my concerns somewhat.
>>
>>> Well, the reality is that people want to use this in the real world and
>>> this is essentially the only way to do it, barring coming up with a
>>> whole new protocol for the purpose (I'm looking at /you/ AJP!).
>>
>> Indeed.
>>
>>> So why not use /the/ protocol that (a) exists and (b) is supported by
>>> every single product that currently supports this type of thing?
>>>
>>>> My support for any patch is going to depend on the specifics of the
>>>> patch.
>>>>
>>>> In addition to the comments in the BZ
>>>> - exposing the data as a request attribute is inconsistent with other
>>>> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
>>>
>>> +1
>>>
>>> The whole point of PROXY is to kind of mix-together the capabilities of
>>> both the RemoteIPFilter/Valve (which uses HTTP headers for
>>> source-information) and the top-level idea of a Connector (something
>>> that binds to a socket and pushes bytes around).
>>>
>>> The confusing thing here is that those two jobs are performed at
>>> relatively different levels in Tomcat at the moment, as I understand
>>> things.
>>
>> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a higher
>> level because that is where they sit but the data originates from the
>> SocketWrapper.
>>
>>> If some kind of UberConnector could be built which essentially does
>>> something like the following, it would be ideal:
>>>
>>> public void accept(Socket s) {
>>> ProxyHeader proxyHeader = readProxyHeader(s);
>>>
>>> Connector realConnector = getRealConnector();
>>>
>>> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>>> realConnector.setRemotePort(proxyHeader.getRemotePort());
>>>
>>> realConnector.takeItAway(s);
>>> }
>>>
>>> I'm sure there are other pieces of information that would be good to
>>> pass-through, but the identity of the remote client is the most
>>> interesting one.
>>
>> Yes, that is the general idea. Just a couple of minor tweaks to use the
>> SocketWrapper rather than the Connector and to do it in a slightly
>> different place. The Acceptor is too early as we want to do as little as
>> possible on the Acceptor thread.
>>
>>>> - needs to be implemented for all Connectors
>>>
>>> I hope not. The connectors should be able to just have a thin layer in
>>> front of them "sipping" the header off the beginning of the connection.
>>> I am *way* out of my depth here when it comes to Tomcat internals and so
>>> I don't want to appear to be telling you (Mark) "how it works/should
>>> work", but conceptually it "seems easy". That may not translate into
>>> "easy implementation" or it may mean "tons of refactoring that we
>>> wouldn't need if we didn't care that much."
>>
>> My point was that the provided patch only implements this for NIO. It
>> needs to implement it for NIO2 as well. APR/Native looks to be a lot
>> more difficult to implement and I'd be happy not implementing it for
>> APR/Native.
>>
>>>> - I'd expect it to look more like the SNI processing
>>>
>>> SNI processing is very connector-dependent, of course, because it's
>>> HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
>>> So if it can be implemented as something that can just "sit in front of"
>>> *any* connector now or in the future of Tomcat, that would be ideal. It
>>> could definitely be implemented as an "optional feature" on a
>>> Connector-by-Connector basis, but my sense is that it can be done
>>> separately and globally.
>>
>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc) whereas I
>> am thinking in terms of implementation (NIO, NIO2, etc).
>>
>> SNI is handled independently of implementation and I think PROXY should
>> be handled the same way. They also sit at almost the same point in the
>> processing (PROXY needs to be first). PROXY parsing could be implemented
>> within the existing handshake() method but I think it would be much
>> cleaner in a separate method.
>>
>> Without looking at it too closely I think the implementation would look
>> something like:
>>
>> - a new method on SocketWrapperBase that
>> - checks if PROXY is enabled
>> - returns immediately if PROXY is not enabled or has already
>> been parsed
>> - uses a new utility class (or classes) to parse the header
>> (reading via the read() methods on SocketWrapperBase)
>> - sets the cached values for remoteAddr, remoteHost,
>> remotePort etc
>> - The SocketProcessor.doRun() implementations add a call to this new
>> method just before the TLS handshake
>>
>> If we want to support the TLS information then a little additional
>> refactoring will be required (probably to cache the result of
>> SocketWrapperBase.getSslSupport) so the new utility classes can insert a
>> PROXY specific SSLSupport implementation.
>>
>>> Again, I'm speaking from a position of profound ignorance, here. Please
>>> don't hear me say "oh, this is easy, Mark... just go do it!" :)
>>
>> :)
>>
>> Actually with the patch that has already been provided and the suggested
>> implementation outline above I don't think there is too much work to do.
>>
>>>> Generally, I don't think implementing this is going to be possible as
>>>> some sort of plug-in.
>>>
>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>> handlers" which is a rather serious commitment.
>>
>> On reflection, with the approach above we probably could implement this
>> via a new plug-in framework but I am not sure it is worth the effort at
>> this point. Something to keep in mind if we have more things wanting to
>> integrate at this point in the processing chain.
>>
>> Mark
>>
>>>
>>> -chris
>>>
>>> [1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
>>> "haproxy"
>>>
>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>> Missed to ask this:
>>>>>
>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>> Was wondering if it would be possible to refactor this patch and/or
>>>>> allow Tomcat core code to extend and plug-in the proxy protocol
>> support?
>>>>>
>>>>> Thanks,
>>>>> Amit
>>>>>
>>>>> -----Original Message-----
>>>>> From: Amit Pande
>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>
>>>>> Chris, Mark,
>>>>>
>>>>> Any thoughts on this?
>>>>>
>>>>> Mark, if we clean up the patch and re-submit, do you will have any
>>>>> concerns (specially security wise)?
>>>>>
>>>>> Thanks,
>>>>> Amit
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>
>>>>> Just a side note, because we're also very interested in this patch!
>>>>>
>>>>> Awhile back, I was successfully able to apply this patch and
>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix
>>>>> domain socket and the Proxy protocol provided *most *of the
>>>>> relevant/required information to tomcat. I believe we had to add a
>>>>> Valve to tomcat to set the Remote IP however as the patch didn't
>>>>> handle that case.
>>>>>
>>>>> I can find my notes from that experiment, but I do remember getting a
>>>>> significant boost in throughput and decrease in latency.
>>>>>
>>>>> +1 for this patch and willing to help out!
>>>>>
>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>> <Am...@veritas.com.invalid>
>>>>> wrote:
>>>>>
>>>>>> Thank you, Chris, again for inputs.
>>>>>> And sorry to circle back on this, late.
>>>>>>
>>>>>> One related question is - does it make sense to use the patch attached
>>>>>> in
>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>
>>>>>> There are concerns from Mark about using the patch in its current
>>>>>> state, but I see last comment (#24) on the issue and looks like there
>>>>>> are some more points to be concluded.
>>>>>>
>>>>>> Thanks,
>>>>>> Amit
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>> To: users@tomcat.apache.org
>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>
>>>>>> Amit,
>>>>>>
>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>> proxy e.g.
>>>>>>>
>>>>>> https://www/.
>>>>>> envoyproxy.io
>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com
>> %7Ca
>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>> which supports the proxy protocol.
>>>>>>>
>>>>>>> Since there is not much action on this
>>>>>> https://bz.a/
>>>>>> pache.org
>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0,
>> does it imply that most of the times Tomcat is running behind HTTP proxies
>> and not TCP proxies?
>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat does
>>>>>>> not
>>>>>> need the remote client address information?
>>>>>>
>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
>>>>>> be able to use a TCP load-balancer because I hide multiple services
>>>>>> behind my reverse-proxy which run in different places. It's not just
>>>>>> s dumb pass-through.
>>>>>>
>>>>>> Hope that helps,
>>>>>> -chris
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Amit,
>>>>>>>
>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>> We have a similar requirement as mentioned in the below enhancement
>>>>>> request.
>>>>>>>>
>>>>>>>> https://bz/.
>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
>>>>>>>> 08
>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
>>>>>>>> 56
>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>>>>> CJ
>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
>>>>>>>> JM
>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>> pache.org
>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>> P
>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
>>>>>>>> c4
>>>>>>>> c
>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
>>>>>>>> sb
>>>>>>>> 3
>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>> D%
>>>>>>>> 7
>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
>>>>>>>> &r
>>>>>>>> e
>>>>>>>> served=0
>>>>>>>>
>>>>>>>> Is there any plan to add this support in Tomcat in future releases?
>>>>>>>
>>>>>>> Nothing at the moment that I know of.
>>>>>>>
>>>>>>> I thought that markt had looked at this a while back and said it
>>>>>>> didn't
>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>> directly and not just rely on Java's SSLServerSocket. I thought that
>>>>>> had been done at some point, but it may not have. Handling the stream
>>>>>> directly may have some other advantages as well, though it definitely
>>>>>> makes the code more complicated.
>>>>>>>
>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>> information from load balancer to Tomcat in situations where there
>>>>>>>> is no SSL termination at load balancer?
>>>>>>> You mean like a network load balancer where the lb is just proxying
>>>>>> bytes and not looking at the data at all? The PROXY protocol really is
>>>>>> the best way to do that, honestly.
>>>>>>>
>>>>>>> -chris
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Jonathan | exabrial@gmail.com
>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see it
>>>>> as half full.
>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>> needs to be.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
On the topic of security, may we consider a trustedProxies setting? This
would be an analog to the internalProxies setting on RemoteIpValve. It
would need to be able to function with APR/NIO listening in a Unix Domain
Socket.
I'm not sure if this is super useful, but the goal would be an added layer
of security to prevent Proxy Protocol header injection.
On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas <ma...@apache.org> wrote:
> On 26/07/2023 21:53, Christopher Schultz wrote:
> > Mark,
> >
> > On 7/26/23 13:58, Mark Thomas wrote:
> >> I'm not a huge fan of this feature in general. I prefer supporting
> >> features backed by specifications rather than vendor specific hacks.
> >
> > I think the PROXY protocol is fairly standard, even if it's not backed
> > by an RFC. It's published by haproxy, but supported by nginx,
> > (obviously) haproxy, AWS, httpd[1], and a whole bunch of others
> > (
> https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address
> ).
>
> ACK. That reduces my concerns somewhat.
>
> > Well, the reality is that people want to use this in the real world and
> > this is essentially the only way to do it, barring coming up with a
> > whole new protocol for the purpose (I'm looking at /you/ AJP!).
>
> Indeed.
>
> > So why not use /the/ protocol that (a) exists and (b) is supported by
> > every single product that currently supports this type of thing?
> >
> >> My support for any patch is going to depend on the specifics of the
> >> patch.
> >>
> >> In addition to the comments in the BZ
> >> - exposing the data as a request attribute is inconsistent with other
> >> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
> >
> > +1
> >
> > The whole point of PROXY is to kind of mix-together the capabilities of
> > both the RemoteIPFilter/Valve (which uses HTTP headers for
> > source-information) and the top-level idea of a Connector (something
> > that binds to a socket and pushes bytes around).
> >
> > The confusing thing here is that those two jobs are performed at
> > relatively different levels in Tomcat at the moment, as I understand
> > things.
>
> Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a higher
> level because that is where they sit but the data originates from the
> SocketWrapper.
>
> > If some kind of UberConnector could be built which essentially does
> > something like the following, it would be ideal:
> >
> > public void accept(Socket s) {
> > ProxyHeader proxyHeader = readProxyHeader(s);
> >
> > Connector realConnector = getRealConnector();
> >
> > realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> > realConnector.setRemotePort(proxyHeader.getRemotePort());
> >
> > realConnector.takeItAway(s);
> > }
> >
> > I'm sure there are other pieces of information that would be good to
> > pass-through, but the identity of the remote client is the most
> > interesting one.
>
> Yes, that is the general idea. Just a couple of minor tweaks to use the
> SocketWrapper rather than the Connector and to do it in a slightly
> different place. The Acceptor is too early as we want to do as little as
> possible on the Acceptor thread.
>
> >> - needs to be implemented for all Connectors
> >
> > I hope not. The connectors should be able to just have a thin layer in
> > front of them "sipping" the header off the beginning of the connection.
> > I am *way* out of my depth here when it comes to Tomcat internals and so
> > I don't want to appear to be telling you (Mark) "how it works/should
> > work", but conceptually it "seems easy". That may not translate into
> > "easy implementation" or it may mean "tons of refactoring that we
> > wouldn't need if we didn't care that much."
>
> My point was that the provided patch only implements this for NIO. It
> needs to implement it for NIO2 as well. APR/Native looks to be a lot
> more difficult to implement and I'd be happy not implementing it for
> APR/Native.
>
> >> - I'd expect it to look more like the SNI processing
> >
> > SNI processing is very connector-dependent, of course, because it's
> > HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
> > So if it can be implemented as something that can just "sit in front of"
> > *any* connector now or in the future of Tomcat, that would be ideal. It
> > could definitely be implemented as an "optional feature" on a
> > Connector-by-Connector basis, but my sense is that it can be done
> > separately and globally.
>
> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc) whereas I
> am thinking in terms of implementation (NIO, NIO2, etc).
>
> SNI is handled independently of implementation and I think PROXY should
> be handled the same way. They also sit at almost the same point in the
> processing (PROXY needs to be first). PROXY parsing could be implemented
> within the existing handshake() method but I think it would be much
> cleaner in a separate method.
>
> Without looking at it too closely I think the implementation would look
> something like:
>
> - a new method on SocketWrapperBase that
> - checks if PROXY is enabled
> - returns immediately if PROXY is not enabled or has already
> been parsed
> - uses a new utility class (or classes) to parse the header
> (reading via the read() methods on SocketWrapperBase)
> - sets the cached values for remoteAddr, remoteHost,
> remotePort etc
> - The SocketProcessor.doRun() implementations add a call to this new
> method just before the TLS handshake
>
> If we want to support the TLS information then a little additional
> refactoring will be required (probably to cache the result of
> SocketWrapperBase.getSslSupport) so the new utility classes can insert a
> PROXY specific SSLSupport implementation.
>
> > Again, I'm speaking from a position of profound ignorance, here. Please
> > don't hear me say "oh, this is easy, Mark... just go do it!" :)
>
> :)
>
> Actually with the patch that has already been provided and the suggested
> implementation outline above I don't think there is too much work to do.
>
> >> Generally, I don't think implementing this is going to be possible as
> >> some sort of plug-in.
> >
> > +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
> > handlers" which is a rather serious commitment.
>
> On reflection, with the approach above we probably could implement this
> via a new plug-in framework but I am not sure it is worth the effort at
> this point. Something to keep in mind if we have more things wanting to
> integrate at this point in the processing chain.
>
> Mark
>
> >
> > -chris
> >
> > [1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
> > "haproxy"
> >
> >> On 26/07/2023 17:44, Amit Pande wrote:
> >>> Missed to ask this:
> >>>
> >>> Looking the patch, it involves modifying Tomcat code.
> >>> Was wondering if it would be possible to refactor this patch and/or
> >>> allow Tomcat core code to extend and plug-in the proxy protocol
> support?
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -----Original Message-----
> >>> From: Amit Pande
> >>> Sent: Wednesday, July 26, 2023 11:43 AM
> >>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> Chris, Mark,
> >>>
> >>> Any thoughts on this?
> >>>
> >>> Mark, if we clean up the patch and re-submit, do you will have any
> >>> concerns (specially security wise)?
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>> -----Original Message-----
> >>> From: Jonathan S. Fisher <ex...@gmail.com>
> >>> Sent: Monday, July 24, 2023 12:41 PM
> >>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> Just a side note, because we're also very interested in this patch!
> >>>
> >>> Awhile back, I was successfully able to apply this patch and
> >>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix
> >>> domain socket and the Proxy protocol provided *most *of the
> >>> relevant/required information to tomcat. I believe we had to add a
> >>> Valve to tomcat to set the Remote IP however as the patch didn't
> >>> handle that case.
> >>>
> >>> I can find my notes from that experiment, but I do remember getting a
> >>> significant boost in throughput and decrease in latency.
> >>>
> >>> +1 for this patch and willing to help out!
> >>>
> >>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
> >>> <Am...@veritas.com.invalid>
> >>> wrote:
> >>>
> >>>> Thank you, Chris, again for inputs.
> >>>> And sorry to circle back on this, late.
> >>>>
> >>>> One related question is - does it make sense to use the patch attached
> >>>> in
> >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> >>>> And potentially, get it integrated into Tomcat versions?
> >>>>
> >>>> There are concerns from Mark about using the patch in its current
> >>>> state, but I see last comment (#24) on the issue and looks like there
> >>>> are some more points to be concluded.
> >>>>
> >>>> Thanks,
> >>>> Amit
> >>>>
> >>>> -----Original Message-----
> >>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>> Sent: Wednesday, May 10, 2023 4:21 PM
> >>>> To: users@tomcat.apache.org
> >>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>
> >>>> Amit,
> >>>>
> >>>> On 5/10/23 12:59, Amit Pande wrote:
> >>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
> >>>>> proxy e.g.
> >>>>>
> >>>> https://www/.
> >>>> envoyproxy.io
> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> >>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com
> %7Ca
> >>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
> >>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> >>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
> >>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> >>>> which supports the proxy protocol.
> >>>>>
> >>>>> Since there is not much action on this
> >>>> https://bz.a/
> >>>> pache.org
> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0,
> does it imply that most of the times Tomcat is running behind HTTP proxies
> and not TCP proxies?
> >>>>> Or does it mean that, Tomcat or applications running in Tomcat does
> >>>>> not
> >>>> need the remote client address information?
> >>>>
> >>>> I can't speak for anybody else, but I use Apache httpd as my
> >>>> reverse-proxy and I do terminate TLS. I also use it for
> >>>> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
> >>>> be able to use a TCP load-balancer because I hide multiple services
> >>>> behind my reverse-proxy which run in different places. It's not just
> >>>> s dumb pass-through.
> >>>>
> >>>> Hope that helps,
> >>>> -chris
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>>>> Sent: Monday, May 8, 2023 3:40 PM
> >>>>> To: users@tomcat.apache.org
> >>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>>>
> >>>>> Amit,
> >>>>>
> >>>>> On 5/4/23 16:07, Amit Pande wrote:
> >>>>>> We have a similar requirement as mentioned in the below enhancement
> >>>> request.
> >>>>>>
> >>>>>> https://bz/.
> >>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
> >>>>>> 08
> >>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
> >>>>>> 56
> >>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >>>>>> CJ
> >>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
> >>>>>> JM
> >>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >>>>>> pache.org
> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >>>>>> P
> >>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
> >>>>>> c4
> >>>>>> c
> >>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
> >>>>>> sb
> >>>>>> 3
> >>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>> D%
> >>>>>> 7
> >>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
> >>>>>> &r
> >>>>>> e
> >>>>>> served=0
> >>>>>>
> >>>>>> Is there any plan to add this support in Tomcat in future releases?
> >>>>>
> >>>>> Nothing at the moment that I know of.
> >>>>>
> >>>>> I thought that markt had looked at this a while back and said it
> >>>>> didn't
> >>>> look too difficult. It does require Tomcat to handle the stream
> >>>> directly and not just rely on Java's SSLServerSocket. I thought that
> >>>> had been done at some point, but it may not have. Handling the stream
> >>>> directly may have some other advantages as well, though it definitely
> >>>> makes the code more complicated.
> >>>>>
> >>>>>> Also, since this was requested long time back and there is no
> >>>>>> update, are there any other alternatives to pass the client
> >>>>>> information from load balancer to Tomcat in situations where there
> >>>>>> is no SSL termination at load balancer?
> >>>>> You mean like a network load balancer where the lb is just proxying
> >>>> bytes and not looking at the data at all? The PROXY protocol really is
> >>>> the best way to do that, honestly.
> >>>>>
> >>>>> -chris
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>> --
> >>> Jonathan | exabrial@gmail.com
> >>> Pessimists, see a jar as half empty. Optimists, in contrast, see it
> >>> as half full.
> >>> Engineers, of course, understand the glass is twice as big as it
> >>> needs to be.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 26/07/2023 21:53, Christopher Schultz wrote:
> Mark,
>
> On 7/26/23 13:58, Mark Thomas wrote:
>> I'm not a huge fan of this feature in general. I prefer supporting
>> features backed by specifications rather than vendor specific hacks.
>
> I think the PROXY protocol is fairly standard, even if it's not backed
> by an RFC. It's published by haproxy, but supported by nginx,
> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others
> (https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address).
ACK. That reduces my concerns somewhat.
> Well, the reality is that people want to use this in the real world and
> this is essentially the only way to do it, barring coming up with a
> whole new protocol for the purpose (I'm looking at /you/ AJP!).
Indeed.
> So why not use /the/ protocol that (a) exists and (b) is supported by
> every single product that currently supports this type of thing?
>
>> My support for any patch is going to depend on the specifics of the
>> patch.
>>
>> In addition to the comments in the BZ
>> - exposing the data as a request attribute is inconsistent with other
>> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
>
> +1
>
> The whole point of PROXY is to kind of mix-together the capabilities of
> both the RemoteIPFilter/Valve (which uses HTTP headers for
> source-information) and the top-level idea of a Connector (something
> that binds to a socket and pushes bytes around).
>
> The confusing thing here is that those two jobs are performed at
> relatively different levels in Tomcat at the moment, as I understand
> things.
Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a higher
level because that is where they sit but the data originates from the
SocketWrapper.
> If some kind of UberConnector could be built which essentially does
> something like the following, it would be ideal:
>
> public void accept(Socket s) {
> ProxyHeader proxyHeader = readProxyHeader(s);
>
> Connector realConnector = getRealConnector();
>
> realConnector.setRemoteIP(proxyHeader.getRemoteIP());
> realConnector.setRemotePort(proxyHeader.getRemotePort());
>
> realConnector.takeItAway(s);
> }
>
> I'm sure there are other pieces of information that would be good to
> pass-through, but the identity of the remote client is the most
> interesting one.
Yes, that is the general idea. Just a couple of minor tweaks to use the
SocketWrapper rather than the Connector and to do it in a slightly
different place. The Acceptor is too early as we want to do as little as
possible on the Acceptor thread.
>> - needs to be implemented for all Connectors
>
> I hope not. The connectors should be able to just have a thin layer in
> front of them "sipping" the header off the beginning of the connection.
> I am *way* out of my depth here when it comes to Tomcat internals and so
> I don't want to appear to be telling you (Mark) "how it works/should
> work", but conceptually it "seems easy". That may not translate into
> "easy implementation" or it may mean "tons of refactoring that we
> wouldn't need if we didn't care that much."
My point was that the provided patch only implements this for NIO. It
needs to implement it for NIO2 as well. APR/Native looks to be a lot
more difficult to implement and I'd be happy not implementing it for
APR/Native.
>> - I'd expect it to look more like the SNI processing
>
> SNI processing is very connector-dependent, of course, because it's
> HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
> So if it can be implemented as something that can just "sit in front of"
> *any* connector now or in the future of Tomcat, that would be ideal. It
> could definitely be implemented as an "optional feature" on a
> Connector-by-Connector basis, but my sense is that it can be done
> separately and globally.
Ah. You are thinking Connector as in protocol (HTTP, AJP, etc) whereas I
am thinking in terms of implementation (NIO, NIO2, etc).
SNI is handled independently of implementation and I think PROXY should
be handled the same way. They also sit at almost the same point in the
processing (PROXY needs to be first). PROXY parsing could be implemented
within the existing handshake() method but I think it would be much
cleaner in a separate method.
Without looking at it too closely I think the implementation would look
something like:
- a new method on SocketWrapperBase that
- checks if PROXY is enabled
- returns immediately if PROXY is not enabled or has already
been parsed
- uses a new utility class (or classes) to parse the header
(reading via the read() methods on SocketWrapperBase)
- sets the cached values for remoteAddr, remoteHost,
remotePort etc
- The SocketProcessor.doRun() implementations add a call to this new
method just before the TLS handshake
If we want to support the TLS information then a little additional
refactoring will be required (probably to cache the result of
SocketWrapperBase.getSslSupport) so the new utility classes can insert a
PROXY specific SSLSupport implementation.
> Again, I'm speaking from a position of profound ignorance, here. Please
> don't hear me say "oh, this is easy, Mark... just go do it!" :)
:)
Actually with the patch that has already been provided and the suggested
implementation outline above I don't think there is too much work to do.
>> Generally, I don't think implementing this is going to be possible as
>> some sort of plug-in.
>
> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
> handlers" which is a rather serious commitment.
On reflection, with the approach above we probably could implement this
via a new plug-in framework but I am not sure it is worth the effort at
this point. Something to keep in mind if we have more things wanting to
integrate at this point in the processing chain.
Mark
>
> -chris
>
> [1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
> "haproxy"
>
>> On 26/07/2023 17:44, Amit Pande wrote:
>>> Missed to ask this:
>>>
>>> Looking the patch, it involves modifying Tomcat code.
>>> Was wondering if it would be possible to refactor this patch and/or
>>> allow Tomcat core code to extend and plug-in the proxy protocol support?
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Amit Pande
>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>> Chris, Mark,
>>>
>>> Any thoughts on this?
>>>
>>> Mark, if we clean up the patch and re-submit, do you will have any
>>> concerns (specially security wise)?
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Jonathan S. Fisher <ex...@gmail.com>
>>> Sent: Monday, July 24, 2023 12:41 PM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>> Just a side note, because we're also very interested in this patch!
>>>
>>> Awhile back, I was successfully able to apply this patch and
>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix
>>> domain socket and the Proxy protocol provided *most *of the
>>> relevant/required information to tomcat. I believe we had to add a
>>> Valve to tomcat to set the Remote IP however as the patch didn't
>>> handle that case.
>>>
>>> I can find my notes from that experiment, but I do remember getting a
>>> significant boost in throughput and decrease in latency.
>>>
>>> +1 for this patch and willing to help out!
>>>
>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>> <Am...@veritas.com.invalid>
>>> wrote:
>>>
>>>> Thank you, Chris, again for inputs.
>>>> And sorry to circle back on this, late.
>>>>
>>>> One related question is - does it make sense to use the patch attached
>>>> in
>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>> And potentially, get it integrated into Tomcat versions?
>>>>
>>>> There are concerns from Mark about using the patch in its current
>>>> state, but I see last comment (#24) on the issue and looks like there
>>>> are some more points to be concluded.
>>>>
>>>> Thanks,
>>>> Amit
>>>>
>>>> -----Original Message-----
>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> Amit,
>>>>
>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>> proxy e.g.
>>>>>
>>>> https://www/.
>>>> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>> which supports the proxy protocol.
>>>>>
>>>>> Since there is not much action on this
>>>> https://bz.a/
>>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
>>>>> Or does it mean that, Tomcat or applications running in Tomcat does
>>>>> not
>>>> need the remote client address information?
>>>>
>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
>>>> be able to use a TCP load-balancer because I hide multiple services
>>>> behind my reverse-proxy which run in different places. It's not just
>>>> s dumb pass-through.
>>>>
>>>> Hope that helps,
>>>> -chris
>>>>
>>>>> -----Original Message-----
>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>
>>>>> Amit,
>>>>>
>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>> We have a similar requirement as mentioned in the below enhancement
>>>> request.
>>>>>>
>>>>>> https://bz/.
>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
>>>>>> 08
>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
>>>>>> 56
>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>>> CJ
>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
>>>>>> JM
>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>> P
>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
>>>>>> c4
>>>>>> c
>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
>>>>>> sb
>>>>>> 3
>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>> D%
>>>>>> 7
>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
>>>>>> &r
>>>>>> e
>>>>>> served=0
>>>>>>
>>>>>> Is there any plan to add this support in Tomcat in future releases?
>>>>>
>>>>> Nothing at the moment that I know of.
>>>>>
>>>>> I thought that markt had looked at this a while back and said it
>>>>> didn't
>>>> look too difficult. It does require Tomcat to handle the stream
>>>> directly and not just rely on Java's SSLServerSocket. I thought that
>>>> had been done at some point, but it may not have. Handling the stream
>>>> directly may have some other advantages as well, though it definitely
>>>> makes the code more complicated.
>>>>>
>>>>>> Also, since this was requested long time back and there is no
>>>>>> update, are there any other alternatives to pass the client
>>>>>> information from load balancer to Tomcat in situations where there
>>>>>> is no SSL termination at load balancer?
>>>>> You mean like a network load balancer where the lb is just proxying
>>>> bytes and not looking at the data at all? The PROXY protocol really is
>>>> the best way to do that, honestly.
>>>>>
>>>>> -chris
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>> --
>>> Jonathan | exabrial@gmail.com
>>> Pessimists, see a jar as half empty. Optimists, in contrast, see it
>>> as half full.
>>> Engineers, of course, understand the glass is twice as big as it
>>> needs to be.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 7/26/23 13:58, Mark Thomas wrote:
> I'm not a huge fan of this feature in general. I prefer supporting
> features backed by specifications rather than vendor specific hacks.
I think the PROXY protocol is fairly standard, even if it's not backed
by an RFC. It's published by haproxy, but supported by nginx,
(obviously) haproxy, AWS, httpd[1], and a whole bunch of others
(https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address).
Well, the reality is that people want to use this in the real world and
this is essentially the only way to do it, barring coming up with a
whole new protocol for the purpose (I'm looking at /you/ AJP!).
So why not use /the/ protocol that (a) exists and (b) is supported by
every single product that currently supports this type of thing?
> My support for any patch is going to depend on the specifics of the patch.
>
> In addition to the comments in the BZ
> - exposing the data as a request attribute is inconsistent with other
> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
+1
The whole point of PROXY is to kind of mix-together the capabilities of
both the RemoteIPFilter/Valve (which uses HTTP headers for
source-information) and the top-level idea of a Connector (something
that binds to a socket and pushes bytes around).
The confusing thing here is that those two jobs are performed at
relatively different levels in Tomcat at the moment, as I understand things.
If some kind of UberConnector could be built which essentially does
something like the following, it would be ideal:
public void accept(Socket s) {
ProxyHeader proxyHeader = readProxyHeader(s);
Connector realConnector = getRealConnector();
realConnector.setRemoteIP(proxyHeader.getRemoteIP());
realConnector.setRemotePort(proxyHeader.getRemotePort());
realConnector.takeItAway(s);
}
I'm sure there are other pieces of information that would be good to
pass-through, but the identity of the remote client is the most
interesting one.
> - needs to be implemented for all Connectors
I hope not. The connectors should be able to just have a thin layer in
front of them "sipping" the header off the beginning of the connection.
I am *way* out of my depth here when it comes to Tomcat internals and so
I don't want to appear to be telling you (Mark) "how it works/should
work", but conceptually it "seems easy". That may not translate into
"easy implementation" or it may mean "tons of refactoring that we
wouldn't need if we didn't care that much."
> - I'd expect it to look more like the SNI processing
SNI processing is very connector-dependent, of course, because it's
HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, anything.
So if it can be implemented as something that can just "sit in front of"
*any* connector now or in the future of Tomcat, that would be ideal. It
could definitely be implemented as an "optional feature" on a
Connector-by-Connector basis, but my sense is that it can be done
separately and globally.
Again, I'm speaking from a position of profound ignorance, here. Please
don't hear me say "oh, this is easy, Mark... just go do it!" :)
> Generally, I don't think implementing this is going to be possible as
> some sort of plug-in.
+1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
handlers" which is a rather serious commitment.
-chris
[1] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for
"haproxy"
> On 26/07/2023 17:44, Amit Pande wrote:
>> Missed to ask this:
>>
>> Looking the patch, it involves modifying Tomcat code.
>> Was wondering if it would be possible to refactor this patch and/or
>> allow Tomcat core code to extend and plug-in the proxy protocol support?
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Amit Pande
>> Sent: Wednesday, July 26, 2023 11:43 AM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> Chris, Mark,
>>
>> Any thoughts on this?
>>
>> Mark, if we clean up the patch and re-submit, do you will have any
>> concerns (specially security wise)?
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Jonathan S. Fisher <ex...@gmail.com>
>> Sent: Monday, July 24, 2023 12:41 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> Just a side note, because we're also very interested in this patch!
>>
>> Awhile back, I was successfully able to apply this patch and terminate
>> TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain
>> socket and the Proxy protocol provided *most *of the relevant/required
>> information to tomcat. I believe we had to add a Valve to tomcat to
>> set the Remote IP however as the patch didn't handle that case.
>>
>> I can find my notes from that experiment, but I do remember getting a
>> significant boost in throughput and decrease in latency.
>>
>> +1 for this patch and willing to help out!
>>
>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>> <Am...@veritas.com.invalid>
>> wrote:
>>
>>> Thank you, Chris, again for inputs.
>>> And sorry to circle back on this, late.
>>>
>>> One related question is - does it make sense to use the patch attached
>>> in
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>> And potentially, get it integrated into Tomcat versions?
>>>
>>> There are concerns from Mark about using the patch in its current
>>> state, but I see last comment (#24) on the issue and looks like there
>>> are some more points to be concluded.
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>> Amit,
>>>
>>> On 5/10/23 12:59, Amit Pande wrote:
>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP proxy
>>>> e.g.
>>>>
>>> https://www/.
>>> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>> which supports the proxy protocol.
>>>>
>>>> Since there is not much action on this
>>> https://bz.a/
>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
>>>> Or does it mean that, Tomcat or applications running in Tomcat does
>>>> not
>>> need the remote client address information?
>>>
>>> I can't speak for anybody else, but I use Apache httpd as my
>>> reverse-proxy and I do terminate TLS. I also use it for
>>> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
>>> be able to use a TCP load-balancer because I hide multiple services
>>> behind my reverse-proxy which run in different places. It's not just
>>> s dumb pass-through.
>>>
>>> Hope that helps,
>>> -chris
>>>
>>>> -----Original Message-----
>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>> To: users@tomcat.apache.org
>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>
>>>> Amit,
>>>>
>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>> We have a similar requirement as mentioned in the below enhancement
>>> request.
>>>>>
>>>>> https://bz/.
>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
>>>>> 08
>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
>>>>> 56
>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>> CJ
>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
>>>>> JM
>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>> P
>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
>>>>> c4
>>>>> c
>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
>>>>> sb
>>>>> 3
>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>> D%
>>>>> 7
>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
>>>>> &r
>>>>> e
>>>>> served=0
>>>>>
>>>>> Is there any plan to add this support in Tomcat in future releases?
>>>>
>>>> Nothing at the moment that I know of.
>>>>
>>>> I thought that markt had looked at this a while back and said it
>>>> didn't
>>> look too difficult. It does require Tomcat to handle the stream
>>> directly and not just rely on Java's SSLServerSocket. I thought that
>>> had been done at some point, but it may not have. Handling the stream
>>> directly may have some other advantages as well, though it definitely
>>> makes the code more complicated.
>>>>
>>>>> Also, since this was requested long time back and there is no
>>>>> update, are there any other alternatives to pass the client
>>>>> information from load balancer to Tomcat in situations where there
>>>>> is no SSL termination at load balancer?
>>>> You mean like a network load balancer where the lb is just proxying
>>> bytes and not looking at the data at all? The PROXY protocol really is
>>> the best way to do that, honestly.
>>>>
>>>> -chris
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>> --
>> Jonathan | exabrial@gmail.com
>> Pessimists, see a jar as half empty. Optimists, in contrast, see it as
>> half full.
>> Engineers, of course, understand the glass is twice as big as it needs
>> to be.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
Mark, thankyou for your feedback. I hope to settle some worry here:
> I prefer supporting features backed by specifications rather than vendor
specific hacks.
I totally understand and agree. This is a standardized specification with a
control document.
Spec: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
The Proxy protocol is actually widely deployed and available today; I'll
provide as many references as I know of:
HaProxy Support: (See spec doc above)
Apache Support:
https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
Nginx Support:
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol
Amazon Web Services Support:
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#proxy-protocol
Google Cloud Support:
https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-protocol
Cloudflare Support:
https://developers.cloudflare.com/spectrum/how-to/enable-proxy-protocol/
DigitalOcean Support:
https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage/#proxy-protocol
Linode Support:
https://www.linode.com/docs/products/networking/nodebalancers/guides/proxy-protocol
These are just the usages that I'm aware of. Having support in Tomcat for
Proxy Protocol means these load balancers above can speak to Tomcat in a
more direct manner. A Google search returns even wider support from
everything on databases to some people supporting this through F5 load
balancers scripts.
Thank you again for your consideration,
On Wed, Jul 26, 2023 at 12:58 PM Mark Thomas <ma...@apache.org> wrote:
> I'm not a huge fan of this feature in general. I prefer supporting
> features backed by specifications rather than vendor specific hacks.
>
> My support for any patch is going to depend on the specifics of the patch.
>
> In addition to the comments in the BZ
> - exposing the data as a request attribute is inconsistent with other
> mechanisms that solve the same problem (e.g. see RemoteIpFilter)
>
> - needs to be implemented for all Connectors
>
> - I'd expect it to look more like the SNI processing
>
> Generally, I don't think implementing this is going to be possible as
> some sort of plug-in.
>
> Mark
>
>
> On 26/07/2023 17:44, Amit Pande wrote:
> > Missed to ask this:
> >
> > Looking the patch, it involves modifying Tomcat code.
> > Was wondering if it would be possible to refactor this patch and/or
> allow Tomcat core code to extend and plug-in the proxy protocol support?
> >
> > Thanks,
> > Amit
> >
> > -----Original Message-----
> > From: Amit Pande
> > Sent: Wednesday, July 26, 2023 11:43 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Chris, Mark,
> >
> > Any thoughts on this?
> >
> > Mark, if we clean up the patch and re-submit, do you will have any
> concerns (specially security wise)?
> >
> > Thanks,
> > Amit
> >
> > -----Original Message-----
> > From: Jonathan S. Fisher <ex...@gmail.com>
> > Sent: Monday, July 24, 2023 12:41 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Just a side note, because we're also very interested in this patch!
> >
> > Awhile back, I was successfully able to apply this patch and terminate
> TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket
> and the Proxy protocol provided *most *of the relevant/required information
> to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP
> however as the patch didn't handle that case.
> >
> > I can find my notes from that experiment, but I do remember getting a
> significant boost in throughput and decrease in latency.
> >
> > +1 for this patch and willing to help out!
> >
> > On Mon, Jul 24, 2023 at 11:22 AM Amit Pande <Amit.Pande@veritas.com
> .invalid>
> > wrote:
> >
> >> Thank you, Chris, again for inputs.
> >> And sorry to circle back on this, late.
> >>
> >> One related question is - does it make sense to use the patch attached
> >> in
> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> >> And potentially, get it integrated into Tomcat versions?
> >>
> >> There are concerns from Mark about using the patch in its current
> >> state, but I see last comment (#24) on the issue and looks like there
> >> are some more points to be concluded.
> >>
> >> Thanks,
> >> Amit
> >>
> >> -----Original Message-----
> >> From: Christopher Schultz <ch...@christopherschultz.net>
> >> Sent: Wednesday, May 10, 2023 4:21 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
> >>
> >> Amit,
> >>
> >> On 5/10/23 12:59, Amit Pande wrote:
> >>> Yes, we intended to have Tomcat run behind a (transparent) TCP proxy
> e.g.
> >>>
> >> https://www/.
> >> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> >> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
> >> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
> >> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> >> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
> >> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> >> which supports the proxy protocol.
> >>>
> >>> Since there is not much action on this
> >> https://bz.a/
> >> pache.org
> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0,
> does it imply that most of the times Tomcat is running behind HTTP proxies
> and not TCP proxies?
> >>> Or does it mean that, Tomcat or applications running in Tomcat does
> >>> not
> >> need the remote client address information?
> >>
> >> I can't speak for anybody else, but I use Apache httpd as my
> >> reverse-proxy and I do terminate TLS. I also use it for
> >> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
> >> be able to use a TCP load-balancer because I hide multiple services
> >> behind my reverse-proxy which run in different places. It's not just s
> dumb pass-through.
> >>
> >> Hope that helps,
> >> -chris
> >>
> >>> -----Original Message-----
> >>> From: Christopher Schultz <ch...@christopherschultz.net>
> >>> Sent: Monday, May 8, 2023 3:40 PM
> >>> To: users@tomcat.apache.org
> >>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >>>
> >>> Amit,
> >>>
> >>> On 5/4/23 16:07, Amit Pande wrote:
> >>>> We have a similar requirement as mentioned in the below enhancement
> >> request.
> >>>>
> >>>> https://bz/.
> >>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
> >>>> 08
> >>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
> >>>> 56
> >>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >>>> CJ
> >>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
> >>>> JM
> >>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >>>> P
> >>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
> >>>> c4
> >>>> c
> >>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
> >>>> sb
> >>>> 3
> >>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>> D%
> >>>> 7
> >>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
> >>>> &r
> >>>> e
> >>>> served=0
> >>>>
> >>>> Is there any plan to add this support in Tomcat in future releases?
> >>>
> >>> Nothing at the moment that I know of.
> >>>
> >>> I thought that markt had looked at this a while back and said it
> >>> didn't
> >> look too difficult. It does require Tomcat to handle the stream
> >> directly and not just rely on Java's SSLServerSocket. I thought that
> >> had been done at some point, but it may not have. Handling the stream
> >> directly may have some other advantages as well, though it definitely
> >> makes the code more complicated.
> >>>
> >>>> Also, since this was requested long time back and there is no
> >>>> update, are there any other alternatives to pass the client
> >>>> information from load balancer to Tomcat in situations where there
> >>>> is no SSL termination at load balancer?
> >>> You mean like a network load balancer where the lb is just proxying
> >> bytes and not looking at the data at all? The PROXY protocol really is
> >> the best way to do that, honestly.
> >>>
> >>> -chris
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> > --
> > Jonathan | exabrial@gmail.com
> > Pessimists, see a jar as half empty. Optimists, in contrast, see it as
> half full.
> > Engineers, of course, understand the glass is twice as big as it needs
> to be.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
I'm not a huge fan of this feature in general. I prefer supporting
features backed by specifications rather than vendor specific hacks.
My support for any patch is going to depend on the specifics of the patch.
In addition to the comments in the BZ
- exposing the data as a request attribute is inconsistent with other
mechanisms that solve the same problem (e.g. see RemoteIpFilter)
- needs to be implemented for all Connectors
- I'd expect it to look more like the SNI processing
Generally, I don't think implementing this is going to be possible as
some sort of plug-in.
Mark
On 26/07/2023 17:44, Amit Pande wrote:
> Missed to ask this:
>
> Looking the patch, it involves modifying Tomcat code.
> Was wondering if it would be possible to refactor this patch and/or allow Tomcat core code to extend and plug-in the proxy protocol support?
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Amit Pande
> Sent: Wednesday, July 26, 2023 11:43 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Chris, Mark,
>
> Any thoughts on this?
>
> Mark, if we clean up the patch and re-submit, do you will have any concerns (specially security wise)?
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Jonathan S. Fisher <ex...@gmail.com>
> Sent: Monday, July 24, 2023 12:41 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Just a side note, because we're also very interested in this patch!
>
> Awhile back, I was successfully able to apply this patch and terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket and the Proxy protocol provided *most *of the relevant/required information to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP however as the patch didn't handle that case.
>
> I can find my notes from that experiment, but I do remember getting a significant boost in throughput and decrease in latency.
>
> +1 for this patch and willing to help out!
>
> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande <Am...@veritas.com.invalid>
> wrote:
>
>> Thank you, Chris, again for inputs.
>> And sorry to circle back on this, late.
>>
>> One related question is - does it make sense to use the patch attached
>> in
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>> And potentially, get it integrated into Tomcat versions?
>>
>> There are concerns from Mark about using the patch in its current
>> state, but I see last comment (#24) on the issue and looks like there
>> are some more points to be concluded.
>>
>> Thanks,
>> Amit
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Wednesday, May 10, 2023 4:21 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> Amit,
>>
>> On 5/10/23 12:59, Amit Pande wrote:
>>> Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
>>>
>> https://www/.
>> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>> which supports the proxy protocol.
>>>
>>> Since there is not much action on this
>> https://bz.a/
>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
>>> Or does it mean that, Tomcat or applications running in Tomcat does
>>> not
>> need the remote client address information?
>>
>> I can't speak for anybody else, but I use Apache httpd as my
>> reverse-proxy and I do terminate TLS. I also use it for
>> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
>> be able to use a TCP load-balancer because I hide multiple services
>> behind my reverse-proxy which run in different places. It's not just s dumb pass-through.
>>
>> Hope that helps,
>> -chris
>>
>>> -----Original Message-----
>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>> Sent: Monday, May 8, 2023 3:40 PM
>>> To: users@tomcat.apache.org
>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>
>>> Amit,
>>>
>>> On 5/4/23 16:07, Amit Pande wrote:
>>>> We have a similar requirement as mentioned in the below enhancement
>> request.
>>>>
>>>> https://bz/.
>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
>>>> 08
>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
>>>> 56
>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>> CJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
>>>> JM
>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>> P
>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
>>>> c4
>>>> c
>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
>>>> sb
>>>> 3
>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>> D%
>>>> 7
>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
>>>> &r
>>>> e
>>>> served=0
>>>>
>>>> Is there any plan to add this support in Tomcat in future releases?
>>>
>>> Nothing at the moment that I know of.
>>>
>>> I thought that markt had looked at this a while back and said it
>>> didn't
>> look too difficult. It does require Tomcat to handle the stream
>> directly and not just rely on Java's SSLServerSocket. I thought that
>> had been done at some point, but it may not have. Handling the stream
>> directly may have some other advantages as well, though it definitely
>> makes the code more complicated.
>>>
>>>> Also, since this was requested long time back and there is no
>>>> update, are there any other alternatives to pass the client
>>>> information from load balancer to Tomcat in situations where there
>>>> is no SSL termination at load balancer?
>>> You mean like a network load balancer where the lb is just proxying
>> bytes and not looking at the data at all? The PROXY protocol really is
>> the best way to do that, honestly.
>>>
>>> -chris
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> --
> Jonathan | exabrial@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full.
> Engineers, of course, understand the glass is twice as big as it needs to be.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Missed to ask this:
Looking the patch, it involves modifying Tomcat code.
Was wondering if it would be possible to refactor this patch and/or allow Tomcat core code to extend and plug-in the proxy protocol support?
Thanks,
Amit
-----Original Message-----
From: Amit Pande
Sent: Wednesday, July 26, 2023 11:43 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
Chris, Mark,
Any thoughts on this?
Mark, if we clean up the patch and re-submit, do you will have any concerns (specially security wise)?
Thanks,
Amit
-----Original Message-----
From: Jonathan S. Fisher <ex...@gmail.com>
Sent: Monday, July 24, 2023 12:41 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
Just a side note, because we're also very interested in this patch!
Awhile back, I was successfully able to apply this patch and terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket and the Proxy protocol provided *most *of the relevant/required information to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP however as the patch didn't handle that case.
I can find my notes from that experiment, but I do remember getting a significant boost in throughput and decrease in latency.
+1 for this patch and willing to help out!
On Mon, Jul 24, 2023 at 11:22 AM Amit Pande <Am...@veritas.com.invalid>
wrote:
> Thank you, Chris, again for inputs.
> And sorry to circle back on this, late.
>
> One related question is - does it make sense to use the patch attached
> in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> And potentially, get it integrated into Tomcat versions?
>
> There are concerns from Mark about using the patch in its current
> state, but I see last comment (#24) on the issue and looks like there
> are some more points to be concluded.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, May 10, 2023 4:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/10/23 12:59, Amit Pande wrote:
> > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> >
> https://www/.
> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> which supports the proxy protocol.
> >
> > Since there is not much action on this
> https://bz.a/
> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> > Or does it mean that, Tomcat or applications running in Tomcat does
> > not
> need the remote client address information?
>
> I can't speak for anybody else, but I use Apache httpd as my
> reverse-proxy and I do terminate TLS. I also use it for
> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
> be able to use a TCP load-balancer because I hide multiple services
> behind my reverse-proxy which run in different places. It's not just s dumb pass-through.
>
> Hope that helps,
> -chris
>
> > -----Original Message-----
> > From: Christopher Schultz <ch...@christopherschultz.net>
> > Sent: Monday, May 8, 2023 3:40 PM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Amit,
> >
> > On 5/4/23 16:07, Amit Pande wrote:
> >> We have a similar requirement as mentioned in the below enhancement
> request.
> >>
> >> https://bz/.
> >> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
> >> 08
> >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
> >> 56
> >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >> CJ
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
> >> JM
> >> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >> P
> >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
> >> c4
> >> c
> >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
> >> sb
> >> 3
> >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >> D%
> >> 7
> >> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
> >> &r
> >> e
> >> served=0
> >>
> >> Is there any plan to add this support in Tomcat in future releases?
> >
> > Nothing at the moment that I know of.
> >
> > I thought that markt had looked at this a while back and said it
> > didn't
> look too difficult. It does require Tomcat to handle the stream
> directly and not just rely on Java's SSLServerSocket. I thought that
> had been done at some point, but it may not have. Handling the stream
> directly may have some other advantages as well, though it definitely
> makes the code more complicated.
> >
> >> Also, since this was requested long time back and there is no
> >> update, are there any other alternatives to pass the client
> >> information from load balancer to Tomcat in situations where there
> >> is no SSL termination at load balancer?
> > You mean like a network load balancer where the lb is just proxying
> bytes and not looking at the data at all? The PROXY protocol really is
> the best way to do that, honestly.
> >
> > -chris
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full.
Engineers, of course, understand the glass is twice as big as it needs to be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Chris, Mark,
Any thoughts on this?
Mark, if we clean up the patch and re-submit, do you will have any concerns (specially security wise)?
Thanks,
Amit
-----Original Message-----
From: Jonathan S. Fisher <ex...@gmail.com>
Sent: Monday, July 24, 2023 12:41 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
Just a side note, because we're also very interested in this patch!
Awhile back, I was successfully able to apply this patch and terminate TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket and the Proxy protocol provided *most *of the relevant/required information to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP however as the patch didn't handle that case.
I can find my notes from that experiment, but I do remember getting a significant boost in throughput and decrease in latency.
+1 for this patch and willing to help out!
On Mon, Jul 24, 2023 at 11:22 AM Amit Pande <Am...@veritas.com.invalid>
wrote:
> Thank you, Chris, again for inputs.
> And sorry to circle back on this, late.
>
> One related question is - does it make sense to use the patch attached
> in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> And potentially, get it integrated into Tomcat versions?
>
> There are concerns from Mark about using the patch in its current
> state, but I see last comment (#24) on the issue and looks like there
> are some more points to be concluded.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, May 10, 2023 4:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/10/23 12:59, Amit Pande wrote:
> > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> >
> https://www/.
> envoyproxy.io%2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca
> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0
> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W
> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
> which supports the proxy protocol.
> >
> > Since there is not much action on this
> https://bz.a/
> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehXvQ%3D&reserved=0, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> > Or does it mean that, Tomcat or applications running in Tomcat does
> > not
> need the remote client address information?
>
> I can't speak for anybody else, but I use Apache httpd as my
> reverse-proxy and I do terminate TLS. I also use it for
> load-balancing/fail-over, caching, some authorization, etc. I wouldn't
> be able to use a TCP load-balancer because I hide multiple services
> behind my reverse-proxy which run in different places. It's not just s dumb pass-through.
>
> Hope that helps,
> -chris
>
> > -----Original Message-----
> > From: Christopher Schultz <ch...@christopherschultz.net>
> > Sent: Monday, May 8, 2023 3:40 PM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Amit,
> >
> > On 5/4/23 16:07, Amit Pande wrote:
> >> We have a similar requirement as mentioned in the below enhancement
> request.
> >>
> >> https://bz/.
> >> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b787206
> >> 08
> >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819350613
> >> 56
> >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >> CJ
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9
> >> JM
> >> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >> P
> >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422
> >> c4
> >> c
> >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZ
> >> sb
> >> 3
> >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >> D%
> >> 7
> >> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D
> >> &r
> >> e
> >> served=0
> >>
> >> Is there any plan to add this support in Tomcat in future releases?
> >
> > Nothing at the moment that I know of.
> >
> > I thought that markt had looked at this a while back and said it
> > didn't
> look too difficult. It does require Tomcat to handle the stream
> directly and not just rely on Java's SSLServerSocket. I thought that
> had been done at some point, but it may not have. Handling the stream
> directly may have some other advantages as well, though it definitely
> makes the code more complicated.
> >
> >> Also, since this was requested long time back and there is no
> >> update, are there any other alternatives to pass the client
> >> information from load balancer to Tomcat in situations where there
> >> is no SSL termination at load balancer?
> > You mean like a network load balancer where the lb is just proxying
> bytes and not looking at the data at all? The PROXY protocol really is
> the best way to do that, honestly.
> >
> > -chris
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full.
Engineers, of course, understand the glass is twice as big as it needs to be.
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by "Jonathan S. Fisher" <ex...@gmail.com>.
Just a side note, because we're also very interested in this patch!
Awhile back, I was successfully able to apply this patch and terminate
TCP/TLS using HaProxy. We then had Tomcat listen on a unix domain socket
and the Proxy protocol provided *most *of the relevant/required information
to tomcat. I believe we had to add a Valve to tomcat to set the Remote IP
however as the patch didn't handle that case.
I can find my notes from that experiment, but I do remember getting a
significant boost in throughput and decrease in latency.
+1 for this patch and willing to help out!
On Mon, Jul 24, 2023 at 11:22 AM Amit Pande <Am...@veritas.com.invalid>
wrote:
> Thank you, Chris, again for inputs.
> And sorry to circle back on this, late.
>
> One related question is - does it make sense to use the patch attached in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
> And potentially, get it integrated into Tomcat versions?
>
> There are concerns from Mark about using the patch in its current state,
> but I see last comment (#24) on the issue and looks like there are some
> more points to be concluded.
>
> Thanks,
> Amit
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, May 10, 2023 4:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/10/23 12:59, Amit Pande wrote:
> > Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> >
> https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency
> which supports the proxy protocol.
> >
> > Since there is not much action on this
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that
> most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> > Or does it mean that, Tomcat or applications running in Tomcat does not
> need the remote client address information?
>
> I can't speak for anybody else, but I use Apache httpd as my reverse-proxy
> and I do terminate TLS. I also use it for load-balancing/fail-over,
> caching, some authorization, etc. I wouldn't be able to use a TCP
> load-balancer because I hide multiple services behind my reverse-proxy
> which run in different places. It's not just s dumb pass-through.
>
> Hope that helps,
> -chris
>
> > -----Original Message-----
> > From: Christopher Schultz <ch...@christopherschultz.net>
> > Sent: Monday, May 8, 2023 3:40 PM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Supporting Proxy Protocol in Tomcat
> >
> > Amit,
> >
> > On 5/4/23 16:07, Amit Pande wrote:
> >> We have a similar requirement as mentioned in the below enhancement
> request.
> >>
> >> https://bz/.
> >> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b78720608
> >> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381935061356
> >> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9JM
> >> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
> >> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
> >> P
> >> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4
> >> c
> >> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb
> >> 3
> >> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >> 7
> >> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D&r
> >> e
> >> served=0
> >>
> >> Is there any plan to add this support in Tomcat in future releases?
> >
> > Nothing at the moment that I know of.
> >
> > I thought that markt had looked at this a while back and said it didn't
> look too difficult. It does require Tomcat to handle the stream directly
> and not just rely on Java's SSLServerSocket. I thought that had been done
> at some point, but it may not have. Handling the stream directly may have
> some other advantages as well, though it definitely makes the code more
> complicated.
> >
> >> Also, since this was requested long time back and there is no update,
> >> are there any other alternatives to pass the client information from
> >> load balancer to Tomcat in situations where there is no SSL
> >> termination at load balancer?
> > You mean like a network load balancer where the lb is just proxying
> bytes and not looking at the data at all? The PROXY protocol really is the
> best way to do that, honestly.
> >
> > -chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jonathan | exabrial@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
RE: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Amit Pande <Am...@veritas.com.INVALID>.
Thank you, Chris, again for inputs.
And sorry to circle back on this, late.
One related question is - does it make sense to use the patch attached in https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
And potentially, get it integrated into Tomcat versions?
There are concerns from Mark about using the patch in its current state, but I see last comment (#24) on the issue and looks like there are some more points to be concluded.
Thanks,
Amit
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, May 10, 2023 4:21 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
Amit,
On 5/10/23 12:59, Amit Pande wrote:
> Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency which supports the proxy protocol.
>
> Since there is not much action on this https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> Or does it mean that, Tomcat or applications running in Tomcat does not need the remote client address information?
I can't speak for anybody else, but I use Apache httpd as my reverse-proxy and I do terminate TLS. I also use it for load-balancing/fail-over, caching, some authorization, etc. I wouldn't be able to use a TCP load-balancer because I hide multiple services behind my reverse-proxy which run in different places. It's not just s dumb pass-through.
Hope that helps,
-chris
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, May 8, 2023 3:40 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/4/23 16:07, Amit Pande wrote:
>> We have a similar requirement as mentioned in the below enhancement request.
>>
>> https://bz/.
>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b78720608
>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6381935061356
>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9ZgtLqUzY9JM
>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>> P
>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4
>> c
>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb
>> 3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7
>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D&r
>> e
>> served=0
>>
>> Is there any plan to add this support in Tomcat in future releases?
>
> Nothing at the moment that I know of.
>
> I thought that markt had looked at this a while back and said it didn't look too difficult. It does require Tomcat to handle the stream directly and not just rely on Java's SSLServerSocket. I thought that had been done at some point, but it may not have. Handling the stream directly may have some other advantages as well, though it definitely makes the code more complicated.
>
>> Also, since this was requested long time back and there is no update,
>> are there any other alternatives to pass the client information from
>> load balancer to Tomcat in situations where there is no SSL
>> termination at load balancer?
> You mean like a network load balancer where the lb is just proxying bytes and not looking at the data at all? The PROXY protocol really is the best way to do that, honestly.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Supporting Proxy Protocol in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Amit,
On 5/10/23 12:59, Amit Pande wrote:
> Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
> https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency which supports the proxy protocol.
>
> Since there is not much action on this https://bz.apache.org/bugzilla/show_bug.cgi?id=57830, does it imply that most of the times Tomcat is running behind HTTP proxies and not TCP proxies?
> Or does it mean that, Tomcat or applications running in Tomcat does not need the remote client address information?
I can't speak for anybody else, but I use Apache httpd as my
reverse-proxy and I do terminate TLS. I also use it for
load-balancing/fail-over, caching, some authorization, etc. I wouldn't
be able to use a TCP load-balancer because I hide multiple services
behind my reverse-proxy which run in different places. It's not just s
dumb pass-through.
Hope that helps,
-chris
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, May 8, 2023 3:40 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Amit,
>
> On 5/4/23 16:07, Amit Pande wrote:
>> We have a similar requirement as mentioned in the below enhancement request.
>>
>> https://bz.a/
>> pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.P
>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e13c0422c4c
>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D&re
>> served=0
>>
>> Is there any plan to add this support in Tomcat in future releases?
>
> Nothing at the moment that I know of.
>
> I thought that markt had looked at this a while back and said it didn't look too difficult. It does require Tomcat to handle the stream directly and not just rely on Java's SSLServerSocket. I thought that had been done at some point, but it may not have. Handling the stream directly may have some other advantages as well, though it definitely makes the code more complicated.
>
>> Also, since this was requested long time back and there is no update,
>> are there any other alternatives to pass the client information from
>> load balancer to Tomcat in situations where there is no SSL
>> termination at load balancer?
> You mean like a network load balancer where the lb is just proxying bytes and not looking at the data at all? The PROXY protocol really is the best way to do that, honestly.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org