You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@httpd.apache.org by GitBox <gi...@apache.org> on 2021/06/02 10:39:10 UTC

[GitHub] [httpd] AlexAT opened a new pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

AlexAT opened a new pull request #191:
URL: https://github.com/apache/httpd/pull/191


   This is related to #68 and is the reimplementation of my original code to 2.4.48, removing all the hacky parts.
   Please tell if anything else needs to be adjusted. If someone is using my older variant (from #68), please test in production to make sure I did not introduce any new bugs (I did the initial testing myself though).
   
   The feature description is:
   mod_remoteip is extended by multiple options handy for frontend proxies moving traffic to Apache backends
   - RemoteAllowOnlyInternalProxies - only allows 'internal' trusted proxies to connect to the Apache server, so no untrusted requests can be done (such are refused with Forbidden)
   - RemoteHostHeader - accepted only from 'internal' trusted proxies, designates name of HTTP header to use as the supplementary Host header used to re-select virtual host inside request processing
   - RemotePortHeader - accepted only from 'internal' trusted proxies, designates name of HTTP header to use as the port number originally used to connect which is used as 'default port' in the request and its subrequests
   - RemoteProtoHeader - accepted only from 'internal' trusted proxies, designates name of HTTP header to supply for HTTPS 'simulation' (only sets the HTTPS used flag internally in the request and its subrequests, so i.e. rewrite conditions work like HTTPS is enabled when the header is present, even if the access to Apache from the proxy is done via HTTP, PHP shows HTTPS enabled, and so on, request HTTP schema is also adjusted)
   - RemoteHTTPSEnableProto - accepted only from 'internal' trusted proxies, supplements RemoteProtoHeader, if set, additionally compares RemoteProtoHeader header contents to the value set and only sets HTTPS emulation if header contents match
   
   ---
   
   Changes to 2.4.41-46 version in #68:
   - No more obscure hacks of SSL module and internal metadata for HTTPS simulation handling and port alteration, rely fully on existing Apache hooks (including new 2.4.48 ssl_conn_is_ssl() hook)
   - Use apr_table_nset() for connection annotation and header changes, we strdup() anyways
   - RemoteHTTPSEnableProto option omitted now means setting HTTPS mode simulation on any RemoteProtoHeader header presence, without verifying header contents, for compatibility with the previous default "RemoteHTTPSEnableProto https" needs to be used


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT commented on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT commented on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-907743668


   I think this also needs some justification about how it's usable. This one was made with shared hosting clusters and frontend-to-backend splits in mind.
   
   - RemoteAllowOnlyInternalProxies is rather trivial, it allows only your trusted frontends to connect, denying all direct requests to backend servers, a safety measure.
   - RemoteHostHeader and RemotePortHeader apply respective header contents after virtual host selection and allow to define a single virtual host for backend, performing real hostname and port mapping on frontends. All .htaccess and other configuration subrequests like rewrite are done to the original virtual host defined in the backend, while i.e. backend scripts see the original Host/Port that were accessed, thinking they are actually running with the specified hostname/port and generating proper URLs from this data. So you can i.e. call your virtual host 'cmr1234.mydomain.com' and map 'yourcustomerhost.com' to 'cmr1234.mydomain.com' on the proxying frontend, sending Host of 'cmr1234.mydomain.com' in the request to backend, and specific headers for the original host/port accessed.
   - RemoteProtoHeader / RemoteHTTPSEnableProto is a widely used feature supplement. It allows to perform all SSL on frontend balancers, while running backend over HTTP only in a trusted network, removing SSL overhead from backends. This allows to create a header to inform backend scripts and other dynamic stuff the original request came via SSL to make it generate HTTPS URLs while the backend will always serve unencrypted. This also affects rewrite conditions so i.e. SSL=on/off dependent rules may be used.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-907743668


   I think this also needs some justification about how it's usable. This one was made with shared hosting clusters and frontend-to-backend splits in mind.
   
   - RemoteAllowOnlyInternalProxies is rather trivial, it allows only your trusted frontends to connect, denying all direct requests to backend servers, a safety measure.
   - RemoteHostHeader and RemotePortHeader apply respective header contents after virtual host selection and allow to define a single virtual host for backend, performing real hostname and port mapping on frontends. All .htaccess and other configuration subrequests like rewrite are done to the original virtual host defined in the backend, while i.e. backend scripts see the original Host/Port that were accessed, thinking they are actually running with the specified hostname/port and generating proper URLs from this data. So you can i.e. call your virtual host 'cmr1234.mydomain.com' and map 'yourcustomerhost.com' to 'cmr1234.mydomain.com' on the proxying frontend, sending Host of 'cmr1234.mydomain.com' in the request to backend, and specific headers for the original host/port accessed.
   - RemoteProtoHeader / RemoteHTTPSEnableProto is a widely used setup supplement. It allows to perform all SSL on frontend balancers, while running backend over HTTP only in a trusted network, removing SSL overhead from backends. This allows to create a header to inform backend scripts and other dynamic stuff the original request came via SSL to make it generate HTTPS URLs while the backend will always serve unencrypted. This also affects rewrite conditions so i.e. SSL=on/off dependent rules may be used. This feature removes the need of tricky SSL/non-SSL state propagation to backends, faking SSL state on the backend and allowing third party stuff to run unmodified in SSL proxy setups.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-853238636


   Added 'static' declaration missing from the initial commit, build passes now. Doublechecked to match running production version.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-907743668


   I think this also needs some justification about how it's usable. This one was made with shared hosting clusters and frontend-to-backend splits in mind.
   
   - RemoteAllowOnlyInternalProxies is rather trivial, it allows only your trusted frontends to connect, denying all direct requests to backend servers, a safety measure.
   - RemoteHostHeader and RemotePortHeader apply respective header contents after virtual host selection and allow to define a single virtual host for backend, performing real hostname and port mapping on frontends. All .htaccess and other configuration subrequests like rewrite are done to the original virtual host defined in the backend, while i.e. backend scripts see the original Host/Port that were accessed, thinking they are actually running with the specified hostname/port and generating proper URLs from this data. So you can i.e. call your virtual host 'cmr1234.mydomain.com' and map 'yourcustomerhost.com' to 'cmr1234.mydomain.com' on the proxying frontend, sending Host of 'cmr1234.mydomain.com' in the request to backend, and specific headers for the original host/port accessed.
   - RemoteProtoHeader / RemoteHTTPSEnableProto is a widely used setup supplement. It allows to perform all SSL on frontend balancers, while running backend over HTTP only in a trusted network, removing SSL overhead from backends. This allows to create a header to inform backend scripts and other dynamic stuff the original request came via SSL to make it generate HTTPS URLs while the backend will always serve unencrypted. This also affects rewrite conditions so i.e. SSL=on/off dependent rules may be used. This feature removes the need of tricky SSL/non-SSL state handling on backends in such setups, faking SSL state and allowing third party stuff to run unmodified in SSL proxy setups.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT commented on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT commented on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-853238636


   Added missing 'static' declaration


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-853238636


   Added 'static' declaration missing from the initial commit, build passes now. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-907743668


   I think this also needs some justification about how it's usable. This one was made with shared hosting clusters and frontend-to-backend splits in mind.
   
   - RemoteAllowOnlyInternalProxies is rather trivial, it allows only your trusted frontends to connect, denying all direct requests to backend servers, a safety measure.
   - RemoteHostHeader and RemotePortHeader apply respective header contents after virtual host selection and allow to define a single virtual host for backend, performing real hostname and port mapping on frontends. All .htaccess and other configuration subrequests like rewrite are done to the original virtual host defined in the backend, while i.e. backend scripts see the original Host/Port that were accessed, thinking they are actually running with the specified hostname/port and generating proper URLs from this data. So you can i.e. call your virtual host 'cmr1234.mydomain.com' and map 'yourcustomerhost.com' to 'cmr1234.mydomain.com' on the proxying frontend, sending Host of 'cmr1234.mydomain.com' in the request to backend, and specific headers for the original host/port accessed.
   - RemoteProtoHeader / RemoteHTTPSEnableProto is a widely used feature supplement. It allows to perform all SSL on frontend balancers, while running backend over HTTP only in a trusted network, removing SSL overhead from backends. This allows to create a header to inform backend scripts and other dynamic stuff the original request came via SSL to make it generate HTTPS URLs while the backend will always serve unencrypted. This also affects rewrite conditions so i.e. SSL=on/off dependent rules may be used. This feature removes the need of tricky SSL/non-SSL state propagation to backends, faking SSL state on the backend.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org


[GitHub] [httpd] AlexAT edited a comment on pull request #191: Reimplementation of remoteip-rpaf for 2.4.48

Posted by GitBox <gi...@apache.org>.
AlexAT edited a comment on pull request #191:
URL: https://github.com/apache/httpd/pull/191#issuecomment-907743668


   I think this also needs some justification about how it's usable. This one was made with shared hosting clusters and frontend-to-backend splits in mind.
   
   - RemoteAllowOnlyInternalProxies is rather trivial, it allows only your trusted frontends to connect, denying all direct requests to backend servers, a safety measure.
   - RemoteHostHeader and RemotePortHeader apply respective header contents after virtual host selection and allow to define a single virtual host for backend, performing real hostname and port mapping on frontends. All .htaccess and other configuration subrequests like rewrite are done to the original virtual host defined in the backend, while i.e. backend scripts see the original Host/Port that were accessed, thinking they are actually running with the specified hostname/port and generating proper URLs from this data. So you can i.e. call your virtual host 'cmr1234.mydomain.com' and map 'yourcustomerhost.com' to 'cmr1234.mydomain.com' on the proxying frontend, sending Host of 'cmr1234.mydomain.com' in the request to backend, and specific headers for the original host/port accessed.
   - RemoteProtoHeader / RemoteHTTPSEnableProto is a widely used feature supplement. It allows to perform all SSL on frontend balancers, while running backend over HTTP only in a trusted network, removing SSL overhead from backends. This allows to create a header to inform backend scripts and other dynamic stuff the original request came via SSL to make it generate HTTPS URLs while the backend will always serve unencrypted. This also affects rewrite conditions so i.e. SSL=on/off dependent rules may be used. This feature removes the need of tricky SSL/non-SSL state propagation to backends, faking SSL state on the backend and allowing third party stuff to run unmodified in SSL proxy setups.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@httpd.apache.org
For additional commands, e-mail: notifications-help@httpd.apache.org