Re: mood_remoteip ProxyProtocol addition

[Sander Hoentjen]

On 02/08/2017 01:00 AM, Reindl Harald wrote:
>
>
> Am 08.02.2017 um 00:44 schrieb Yann Ylavic:
>> On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic 
>> wrote:
>>> On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald
>>>  wrote:

 how can you trust as a php application developer that
 "X-Forwarded-Proto" is
 trustable and not from the enduser client at all - for REMOTE_ADDR
 you don't
 consider "X-Forwarded-For" exactly for that reason
>>>
>>> I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
>>> that mod_remoteip [either directly or provides the (optional)
>>> functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
>>> and/or REMOTE_SCHEME=https accordingly.
>>> Just like REMOTE_ADDR.
>>>
>>> But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
>>> sources/hooks as accessed and read by core/modules), like (IIUC)
>>> proposed by the patches.
>>> These are local informations.
>>
>> Actually, I'm not really opposed to set HTTPS=on (according to
>> mod_remoteip) in the environment *given to the script/CGI* only, if
>> that's the trigger for it to do the desired thing, this won't be used
>> by httpd internally at least.
>>
>> What's proposed so far is much more than that (if I read the patches
>> correctly)
>
> ok, so finally we agree :-)
>
> i am only interested in a centralized way to get rid of hacks like
> below in each and every application where mod_remoteip solves the
> similar problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php
>
> $_SERVER['REQUEST_SCHEME'] because you typically build a full
> qualifiied URL for a link in emails with $_SERVER['REQUEST_SCHEME'] .
> '//' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'
>
> in my own application the hack below was simple - in case of other
> software like Magento and so on you have to hack "index.php" while at
> the same time you should not touch the application code to keep it
> easily updateable
>
> if(!empty($config['cms_tls_offload']))
> {
>  $_SERVER['SERVER_PORT']= '443';
>  $_SERVER['REQUEST_SCHEME'] = 'https';
>  $_SERVER['HTTPS']  = 'on';
> }
>
As the OP, first let me say sorry for the typo in the subject.
Now, I must say that I agree too about anything that has been said in
this thread so far.
There should be a standard way for applications to check information.
Unfortunately, historically the way applications(1) deal with it varies
a bit. In a .htaccess the things most seen are:

RewriteCond %{HTTPS} !=on
RewriteCond %{SERVER_PORT} ^443$ [OR]
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Basically, if those stop working I am screwed.

Then, on to PHP:
I think most of them check the HTTPS env var ($_SERVER['HTTPS']) but
some check REQUEST_SCHEME or SERVER_PORT. Probably some users are even
more creative.

Of course, there are also those who check things like
HTTP_X_FORWARDED_PROTO in addition.

Because we have lots of customers, it would be virtually impossible to
"fix" all their applications.

Onto the subject of security:
As the system administrator of those servers, I could choose to do SSL
ofloading, non-encrypted to a proxy, then that proxy uses an Apache SSL
backend. In this case the connection is as (in)secure as the case where
the SSL-offloader talks directly to Apache. But, applications would
continue to work. On the matter of PHP applications I would like to add
that PHP-FPM also does not have encryption. From an end-user security
POV there would be (IMHO) no difference between SSL-offloader -> Apache
-> PHP-FPM and Apache -> PHP-FPM.

The thing I am trying to say here is that for the most part, it is up to
the system administrator to configure things securely. It would help if
Apache allows the sysadmin to choose. Of course it is important to think
really hard about what is allowed and what not, so I am glad this
discussion is taking place.


(1) I work at a hosting provider, so I am talking mostly about PHP
"applications"

-- 
Sander

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 8 February 2017 at 01:44, Yann Ylavic  wrote:
> Actually, I'm not really opposed to set HTTPS=on (according to
> mod_remoteip) in the environment *given to the script/CGI* only, if
> that's the trigger for it to do the desired thing, this won't be used
> by httpd internally at least.
>
> What's proposed so far is much more than that (if I read the patches 
> correctly).

Well, another proposal that wasn't in the patches, but was discussed
in bugzilla was to decouple mod_rewrite's HTTPS check from calling
mod_ssl directly and make it just check the environment variable, so
that rewrite conditions relying on it will still work behind a proxy.

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 08.02.2017 um 00:44 schrieb Yann Ylavic:

On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic  wrote:

On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:


how can you trust as a php application developer that "X-Forwarded-Proto" is
trustable and not from the enduser client at all - for REMOTE_ADDR you don't
consider "X-Forwarded-For" exactly for that reason


I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.

But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.


Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.

What's proposed so far is much more than that (if I read the patches correctly)


ok, so finally we agree :-)

i am only interested in a centralized way to get rid of hacks like below 
in each and every application where mod_remoteip solves the similar 
problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php


$_SERVER['REQUEST_SCHEME'] because you typically build a full qualifiied 
URL for a link in emails with $_SERVER['REQUEST_SCHEME'] . '//' . 
$_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'


in my own application the hack below was simple - in case of other 
software like Magento and so on you have to hack "index.php" while at 
the same time you should not touch the application code to keep it 
easily updateable


if(!empty($config['cms_tls_offload']))
{
 $_SERVER['SERVER_PORT']= '443';
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic  wrote:
> On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:
>>
>> how can you trust as a php application developer that "X-Forwarded-Proto" is
>> trustable and not from the enduser client at all - for REMOTE_ADDR you don't
>> consider "X-Forwarded-For" exactly for that reason
>
> I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
> that mod_remoteip [either directly or provides the (optional)
> functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
> and/or REMOTE_SCHEME=https accordingly.
> Just like REMOTE_ADDR.
>
> But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
> sources/hooks as accessed and read by core/modules), like (IIUC)
> proposed by the patches.
> These are local informations.

Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.

What's proposed so far is much more than that (if I read the patches correctly).

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:
>
> how can you trust as a php application developer that "X-Forwarded-Proto" is
> trustable and not from the enduser client at all - for REMOTE_ADDR you don't
> consider "X-Forwarded-For" exactly for that reason

I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.

But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 23:50 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 11:34 PM, Reindl Harald  wrote:


Am 07.02.2017 um 22:53 schrieb Yann Ylavic:


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have not
secure way to know for sure if that header is trustable, when mod_remoteip
is part of the game you even don't know (and should not know) the physical
connecting IP


I agree with that, "X-Forwarded-Proto or whatever" was meant to say "a
trustable information", and I even agree that's mod_remoteip's job to
give that information.

I just don't think we should make as if httpd were running https (i.e.
for all modules/applications to think it is), but rather give the real
information: trustable remote is running https


with a wayback machine this would be pretty cool, but whatever you do at 
this point in time needs to


a) get implemented in the tls offlaoding software
b) get implemented in the backend-server (httpd)
c) get implemented in each and every web application

while a) and b) are realistic in a mid-term timeframe c) is not and 
additionally c) needs to to it secure


to do it secure is even a real problem

how can you trust as a php application developer that 
"X-Forwarded-Proto" is trustable and not from the enduser client at all 
- for REMOTE_ADDR you don't consider "X-Forwarded-For" exactly for that 
reason


when mod_remoteip is in place "X-Forwarded-For" contains only untrusted 
informations and the ip of your own proxy is ripped out of that header


without mod_remoteip you get unfiltered whatever came over the wire and 
you have no idea within the php application if you are behind a proxy at 
all


at least not trusted one and even if httpd promises in a later version 
that you don't get that header from untrusted sources you have no idea 
if the httpd on your hoster has that promise (LTS distributions with no 
real versions) and there are other webservers too


hence application developers are advised making no decisions based on 
that header - i would find it questionable having a "X-Forwarded-Proto" 
where you have to deal with in the application and "X-Forwarded-For" 
where you *must not* process it for security reasons

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 11:34 PM, Reindl Harald  wrote:
>
> Am 07.02.2017 um 22:53 schrieb Yann Ylavic:
>>
>> I mean the application can know about "X-Forwarded-Proto or whatever"
>> header, it could act with it like it does with HTTPS=on (if it
>> wishes)
>
> for that you would need to touch each and every application and you have not
> secure way to know for sure if that header is trustable, when mod_remoteip
> is part of the game you even don't know (and should not know) the physical
> connecting IP

I agree with that, "X-Forwarded-Proto or whatever" was meant to say "a
trustable information", and I even agree that's mod_remoteip's job to
give that information.

I just don't think we should make as if httpd were running https (i.e.
for all modules/applications to think it is), but rather give the real
information: trustable remote is running https.

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 22:53 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov  wrote:

On 7 February 2017 at 22:33, Yann Ylavic  wrote:

I'm a bit reluctant with these patches, and probably need to be
convinced this isn't an application issue in the first place (why not
use X-Forwarded-Proto or alike to achieve the same? i.e. generate
https links...), or an SSL endpoint issue (why not rewrite URLs or
alike there?).

It can be X-Forwarded-Proto or whatever you set it to with my patch
(for the standard method of proxying).
I can't speak to the ProxyProtocol one.

I also don't see what you mean by an "application issue".


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have 
not secure way to know for sure if that header is trustable, when 
mod_remoteip is part of the game you even don't know (and should not 
know) the physical connecting IP


and so when you write a application to directly proceed that header you 
make your application vulnerable in every environment where the outside 
client fakes that header


dealing with it the same way as for REMOTE_ADDR would make it 100% 
transparent for the application and it would only trigger if the admin 
configured the underlying server as he does with mod_remoteip's 
"RemoteIPInternalProxy"


it's not a application issue - the application must not know anything 
about infrastructure decisions - it's the job of the underlying 
infrastructure

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 21:33 schrieb Yann Ylavic:

My point is that we are not changing/masquarading something which is
remote here (like the client IP address), we are making so that the
applications and httpd itself think they are locally talking SSL/TLS.
Thus they will send things like "; Secure" cookies in "clear" on the
wire, or anything which is expected to not be eavesdrop-able.

I'd like others from the community to give their opinions here, for
now I find this quite opposite to TLS principles/expectations...


it's exactly how it should work - proxy to backend unencrypted, caching 
on the proxy and transport security between proxy endpoint and web client


that is what is meant by "TLS offloading" - it's not your problem how 
secure that wire is, on our VMware-cluster the hosts even don#t talk 
about a switch - they are directly connected for internal traffic and so 
that wire is as secure as the virtual machine itself

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov  wrote:
> On 7 February 2017 at 22:33, Yann Ylavic  wrote:
>> I'm a bit reluctant with these patches, and probably need to be
>> convinced this isn't an application issue in the first place (why not
>> use X-Forwarded-Proto or alike to achieve the same? i.e. generate
>> https links...), or an SSL endpoint issue (why not rewrite URLs or
>> alike there?).
> It can be X-Forwarded-Proto or whatever you set it to with my patch
> (for the standard method of proxying).
> I can't speak to the ProxyProtocol one.
>
> I also don't see what you mean by an "application issue".

I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes).

>
>>
>> My point is that we are not changing/masquarading something which is
>> remote here (like the client IP address), we are making so that the
>> applications and httpd itself think they are locally talking SSL/TLS.
>> Thus they will send things like "; Secure" cookies in "clear" on the
>> wire, or anything which is expected to not be eavesdrop-able.
> The whole point of the mod_remoteip is that it tells you the request
> is forwarded by a trusted source, usually over an internal network, so
> I don't see what eavesdropping

It tells you what remote information of the request is trustable,
which is not the same (IMHO) as a local information like _this_ server
(running the application) is using https.

>
>> I'd like others from the community to give their opinions here, for
>> now I find this quite opposite to TLS principles/expectations...
> It's made to work much like Apache Tomcat's RemoteIPValve. Different
> language, same principal.
>
> I've only used a few PHP frameworks, but whenever they require
> checking if the server is secure and redirecting if not, they always
> fall back on these three variables that are changed.
> HTTPS = on
> REQUEST_SCHEME = https
> SERVER_PORT = 443 (some times configurable).

That's what I called an application issue, I don't see why PHP
wouldn't trust other variables if PHP users want to, or the
application/script force those (or whatever) for _PHP_ to act as if,
or the act as if directly...

Why would the server lie? I'd be fine with the server setting
REMOTE_HTTPS=on and/or REMOTE_SCHEME=https, though.

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 7 February 2017 at 22:33, Yann Ylavic  wrote:
> I'm a bit reluctant with these patches, and probably need to be
> convinced this isn't an application issue in the first place (why not
> use X-Forwarded-Proto or alike to achieve the same? i.e. generate
> https links...), or an SSL endpoint issue (why not rewrite URLs or
> alike there?).
It can be X-Forwarded-Proto or whatever you set it to with my patch
(for the standard method of proxying).
I can't speak to the ProxyProtocol one.

I also don't see what you mean by an "application issue".

>
> My point is that we are not changing/masquarading something which is
> remote here (like the client IP address), we are making so that the
> applications and httpd itself think they are locally talking SSL/TLS.
> Thus they will send things like "; Secure" cookies in "clear" on the
> wire, or anything which is expected to not be eavesdrop-able.
The whole point of the mod_remoteip is that it tells you the request
is forwarded by a trusted source, usually over an internal network, so
I don't see what eavesdropping

> I'd like others from the community to give their opinions here, for
> now I find this quite opposite to TLS principles/expectations...
It's made to work much like Apache Tomcat's RemoteIPValve. Different
language, same principal.

I've only used a few PHP frameworks, but whenever they require
checking if the server is secure and redirecting if not, they always
fall back on these three variables that are changed.
HTTPS = on
REQUEST_SCHEME = https
SERVER_PORT = 443 (some times configurable).

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 7:03 PM, Jordan Gigov  wrote:
> On 7 February 2017 at 18:08, Sander Hoentjen  wrote:
>>
>> I am trying to have haproxy added in front of our Apache servers, for
>> SSL termination. This is not hard to do, and especially with the recent
>> addition of ProxyProtocol support to mod_remoteip it works almost as we
>> need it.
>> Unfortunately we have a lot of users that use things like:
>> RewriteCond %{HTTPS} !on
>> in their .htaccess, and stuff like:
>> if $_SERVER['HTTPS']
>> in their PHP code.
>>
>> [1] https://github.com/AntagonistHQ/httpd/tree/remote-ssl
>
> I submitted an issue and a patch for that some time ago.
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59829

I'm a bit reluctant with these patches, and probably need to be
convinced this isn't an application issue in the first place (why not
use X-Forwarded-Proto or alike to achieve the same? i.e. generate
https links...), or an SSL endpoint issue (why not rewrite URLs or
alike there?).

My point is that we are not changing/masquarading something which is
remote here (like the client IP address), we are making so that the
applications and httpd itself think they are locally talking SSL/TLS.
Thus they will send things like "; Secure" cookies in "clear" on the
wire, or anything which is expected to not be eavesdrop-able.

I'd like others from the community to give their opinions here, for
now I find this quite opposite to TLS principles/expectations...


Regards,
Yann.

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 7 February 2017 at 18:08, Sander Hoentjen  wrote:
> Hi guys,
>
> I am trying to have haproxy added in front of our Apache servers, for
> SSL termination. This is not hard to do, and especially with the recent
> addition of ProxyProtocol support to mod_remoteip it works almost as we
> need it.
> Unfortunately we have a lot of users that use things like:
> RewriteCond %{HTTPS} !on
> in their .htaccess, and stuff like:
> if $_SERVER['HTTPS']
> in their PHP code.
>
> Long story short, I need httpd to act like SSL is on, if the haproxy
> instance says it is.
> Fortunately the proxy protocol supports this, and haproxy can send it.
> I have created a patch [1] that adds support for reading this in httpd,
> but I have never before done something with the httpd source code. And,
> as a matter of fact, have never really programmed in C before.
>
> I am hoping you would be willing to have a look at it and tell me all
> the things I am doing wrong. Eventually it would be awesome if the code
> could be added to apache itself.
>
> [1] https://github.com/AntagonistHQ/httpd/tree/remote-ssl
>
> Kind regards,
> Sander Hoentjen

I submitted an issue and a patch for that some time ago.

https://bz.apache.org/bugzilla/show_bug.cgi?id=59829

Recently updated it to the 2.5 trunk version, but it does not respect
the new ProxyProtocol stuff, which frankly I know nothing about.
It only works for the older proxy method.