You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2012/09/30 10:17:07 UTC
[jira] [Created] (FELIX-3693) Filter for servers running behind a
SSL-endpoint proxy
Felix Meschberger created FELIX-3693:
----------------------------------------
Summary: Filter for servers running behind a SSL-endpoint proxy
Key: FELIX-3693
URL: https://issues.apache.org/jira/browse/FELIX-3693
Project: Felix
Issue Type: New Feature
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Problem: A an OSGi based application (e.g. an Apache Sling instance) operates behind an HTTP Proxy. Clients contact the proxy with HTTPS (SSL) while the proxy contacts the application over plain HTTP. The information that the client is using HTTPS/SSL is lost along the way.
>From the POV of the application all requests are not secured since the ServletRequest.isSecure() method always returns false.
This creates some trouble particularly when sending absolute links (including the scheme) or redirects back to the client. Another issue is cookies which should be set to "secure" if the client is using HTTPS.
The general concept is as follows:
(1) The proxy is configured to set a request header when being the SSL endpoint (talking SSL to clients and talking plain HTTP to application) for the application to act as if handling a secure request:
(1a) X-Forwarded-SSL: on (see Making HTTPS Redirects Work With a Reverse Proxy at http://www.turbogears.org/1.0/docs/Install/RedirectHttpsRequests.html)
(1b) Optionally set other headers to provide the cipher_suite, key_size, and ssl_session_id. If the proxy is not able to derive these values from, the information just cannot be provided, which is not problematic
(2) A servlet filter is implemented to act upon the headers provided by the proxy, creating a request wrapper as follows:
(2a) overwrite ServletRequest.getScheme, ServletRequest.isSecure, HttpServletRequest.getRequestURL to indicate HTTPS
(2b) Set the request attributes defined by the Servlet API spec if the respective information is available from the dispatcher. Otherwise the attributes remain undefined
This issue is about implementing the second part as a servlet filter to support a proxy configured as described in the first part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3693) Filter for servers running behind a
SSL-endpoint proxy
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved FELIX-3693.
--------------------------------------
Resolution: Fixed
Fix Version/s: http-sslfilter-1.0.0
Added a first implementation of the filter in Rev. 1394715
This first implementation is not currently configurable.
> Filter for servers running behind a SSL-endpoint proxy
> ------------------------------------------------------
>
> Key: FELIX-3693
> URL: https://issues.apache.org/jira/browse/FELIX-3693
> Project: Felix
> Issue Type: New Feature
> Components: HTTP Service
> Affects Versions: http-2.2.0
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: http-sslfilter-1.0.0
>
>
> Problem: A an OSGi based application (e.g. an Apache Sling instance) operates behind an HTTP Proxy. Clients contact the proxy with HTTPS (SSL) while the proxy contacts the application over plain HTTP. The information that the client is using HTTPS/SSL is lost along the way.
> From the POV of the application all requests are not secured since the ServletRequest.isSecure() method always returns false.
> This creates some trouble particularly when sending absolute links (including the scheme) or redirects back to the client. Another issue is cookies which should be set to "secure" if the client is using HTTPS.
> The general concept is as follows:
> (1) The proxy is configured to set a request header when being the SSL endpoint (talking SSL to clients and talking plain HTTP to application) for the application to act as if handling a secure request:
> (1a) X-Forwarded-SSL: on (see Making HTTPS Redirects Work With a Reverse Proxy at http://www.turbogears.org/1.0/docs/Install/RedirectHttpsRequests.html)
> (1b) Optionally set other headers to provide the cipher_suite, key_size, and ssl_session_id. If the proxy is not able to derive these values from, the information just cannot be provided, which is not problematic
> (2) A servlet filter is implemented to act upon the headers provided by the proxy, creating a request wrapper as follows:
> (2a) overwrite ServletRequest.getScheme, ServletRequest.isSecure, HttpServletRequest.getRequestURL to indicate HTTPS
> (2b) Set the request attributes defined by the Servlet API spec if the respective information is available from the dispatcher. Otherwise the attributes remain undefined
> This issue is about implementing the second part as a servlet filter to support a proxy configured as described in the first part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira