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 <ylavic....@gmail.com>
>> wrote:
>>> On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald
>>> <h.rei...@thelounge.net> 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
