You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Ben Johnson <be...@indietorrent.org> on 2012/09/27 17:06:40 UTC
[users@httpd] Forcing SSL while redirecting with query string intact, preventing
"double-login problem" and preventing plaintext authentication
Hello,
Over the years, I've experimented with a number of mechanisms by which
to force SSL connections to a website, while at the same time:
a.) Preventing the "double-login" problem.
b.) Eliminating entirely the potential for users to log-in over a
plain-text connection.
c.) Redirecting plain-text requests (including their query strings) to
equivalent URLs over SSL, transparently, *even when Apache
authentication is required*. (This is to avoid sending "Access denied"
responses when SSL is required but the connection is plain-text.)
Is it even possible to meet all of these requirements simultaneously?
To address requirement a), I have done the following, traditionally:
<Location /securesite>
SSLOptions +StrictRequire
SSLRequireSSL
ErrorDocument 403 https://example.com/securesite
</Location>
This works well enough, and satisfies requirements a) and b), but if I'm
not mistaken, it precludes requirement c) from being met. Right?
Wouldn't a *plaintext* request to /some/arbitrary/path?foo=bar&foo2=bar2
force a redirection to the ErrorDocument location, while dropping
everything after /securesite? That is the observed behavior, and it
makes sense.
I tried appending %{REQUEST_URI} to the ErrorDocument location, but that
variable appears not to be available and is not expanded, so the request
is redirected to /securesite/%%7BREQUEST_URI%7D (doesn't work, needless
to say).
Could this be due to the following (from the Apache documentation at
http://httpd.apache.org/docs/2.2/custom-error.html#behavior ):
"At least REDIRECT_URL and REDIRECT_QUERY_STRING will be passed to the
new URL (assuming it's a cgi-script or a cgi-include). The other
variables will exist only if they existed prior to the error/problem.
None of these will be set if your ErrorDocument is an external redirect
(anything starting with a scheme name like http:, even if it refers to
the same host as the server)."
I realize that the last bit of this quote applies directly to this
situation, and is likely the reason for which using %{REQUEST_URI} does
not work in this context. But if I remove the https scheme from the
ErrorDocument directive, then this rule is no longer effective.
Does anyone have any thoughts as to how I can meet all three requirements?
Thanks for any help!
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Forcing SSL while redirecting with query string
intact, preventing "double-login problem" and preventing plaintext authentication
Posted by Ben Johnson <be...@indietorrent.org>.
On 9/27/2012 11:55 AM, Yehuda Katz wrote:
> We use mod_rewrite (non-relevant config removed):
>
> <VirtualHost *:80>
> <Directory /var/www/admin>
> RewriteEngine On
> RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
> </Directory>
> </VirtualHost>
> <VirtualHost _default_:443>
> AddExternalAuth pwauth /usr/sbin/pwauth
> SetExternalAuthMethod pwauth pipe
>
> <Directory /var/www/admin/>
> AuthBasicProvider external
> AuthExternal pwauth
>
> AuthType Basic
> AuthName "Admin"
>
> AuthzUnixgroup on
> Require group sudo
> </Directory>
> </VirtualHost>
>
> - Y
>
Thank you very much for the response, Yehuda. That is an elegant
solution, and one that I had considered.
The only reason I avoided it is that I'm using ISPConfig, which
automatically writes the exact same set of directives to both blocks (80
and 443) within the virtual host configuration. While convenient, this
makes it a challenge to implement anything like the above.
Maybe I'll submit a feature request to ISPConfig: provide a second,
separate text area input for Apache configuration directives when SSL is
enabled.
Thanks again!
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Forcing SSL while redirecting with query string
intact, preventing "double-login problem" and preventing plaintext authentication
Posted by Yehuda Katz <ye...@ymkatz.net>.
We use mod_rewrite (non-relevant config removed):
<VirtualHost *:80>
<Directory /var/www/admin>
RewriteEngine On
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>
</VirtualHost>
<VirtualHost _default_:443>
AddExternalAuth pwauth /usr/sbin/pwauth
SetExternalAuthMethod pwauth pipe
<Directory /var/www/admin/>
AuthBasicProvider external
AuthExternal pwauth
AuthType Basic
AuthName "Admin"
AuthzUnixgroup on
Require group sudo
</Directory>
</VirtualHost>
- Y
On Thu, Sep 27, 2012 at 11:06 AM, Ben Johnson <be...@indietorrent.org> wrote:
> Hello,
>
> Over the years, I've experimented with a number of mechanisms by which
> to force SSL connections to a website, while at the same time:
>
> a.) Preventing the "double-login" problem.
>
> b.) Eliminating entirely the potential for users to log-in over a
> plain-text connection.
>
> c.) Redirecting plain-text requests (including their query strings) to
> equivalent URLs over SSL, transparently, *even when Apache
> authentication is required*. (This is to avoid sending "Access denied"
> responses when SSL is required but the connection is plain-text.)
>
> Is it even possible to meet all of these requirements simultaneously?
>
> To address requirement a), I have done the following, traditionally:
>
> <Location /securesite>
> SSLOptions +StrictRequire
> SSLRequireSSL
> ErrorDocument 403 https://example.com/securesite
> </Location>
>
> This works well enough, and satisfies requirements a) and b), but if I'm
> not mistaken, it precludes requirement c) from being met. Right?
> Wouldn't a *plaintext* request to /some/arbitrary/path?foo=bar&foo2=bar2
> force a redirection to the ErrorDocument location, while dropping
> everything after /securesite? That is the observed behavior, and it
> makes sense.
>
> I tried appending %{REQUEST_URI} to the ErrorDocument location, but that
> variable appears not to be available and is not expanded, so the request
> is redirected to /securesite/%%7BREQUEST_URI%7D (doesn't work, needless
> to say).
>
> Could this be due to the following (from the Apache documentation at
> http://httpd.apache.org/docs/2.2/custom-error.html#behavior ):
>
> "At least REDIRECT_URL and REDIRECT_QUERY_STRING will be passed to the
> new URL (assuming it's a cgi-script or a cgi-include). The other
> variables will exist only if they existed prior to the error/problem.
> None of these will be set if your ErrorDocument is an external redirect
> (anything starting with a scheme name like http:, even if it refers to
> the same host as the server)."
>
> I realize that the last bit of this quote applies directly to this
> situation, and is likely the reason for which using %{REQUEST_URI} does
> not work in this context. But if I remove the https scheme from the
> ErrorDocument directive, then this rule is no longer effective.
>
> Does anyone have any thoughts as to how I can meet all three requirements?
>
> Thanks for any help!
>
> -Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Forcing SSL while redirecting with query string
intact, preventing "double-login problem" and preventing plaintext authentication
Posted by Ben Johnson <be...@indietorrent.org>.
On 9/27/2012 11:06 AM, Ben Johnson wrote:
> Hello,
>
> Over the years, I've experimented with a number of mechanisms by which
> to force SSL connections to a website, while at the same time:
>
> a.) Preventing the "double-login" problem.
>
> b.) Eliminating entirely the potential for users to log-in over a
> plain-text connection.
>
> c.) Redirecting plain-text requests (including their query strings) to
> equivalent URLs over SSL, transparently, *even when Apache
> authentication is required*. (This is to avoid sending "Access denied"
> responses when SSL is required but the connection is plain-text.)
>
> Is it even possible to meet all of these requirements simultaneously?
>
> To address requirement a), I have done the following, traditionally:
>
> <Location /securesite>
> SSLOptions +StrictRequire
> SSLRequireSSL
> ErrorDocument 403 https://example.com/securesite
> </Location>
>
> This works well enough, and satisfies requirements a) and b), but if I'm
> not mistaken, it precludes requirement c) from being met. Right?
> Wouldn't a *plaintext* request to /some/arbitrary/path?foo=bar&foo2=bar2
> force a redirection to the ErrorDocument location, while dropping
> everything after /securesite? That is the observed behavior, and it
> makes sense.
>
> I tried appending %{REQUEST_URI} to the ErrorDocument location, but that
> variable appears not to be available and is not expanded, so the request
> is redirected to /securesite/%%7BREQUEST_URI%7D (doesn't work, needless
> to say).
>
> Could this be due to the following (from the Apache documentation at
> http://httpd.apache.org/docs/2.2/custom-error.html#behavior ):
>
> "At least REDIRECT_URL and REDIRECT_QUERY_STRING will be passed to the
> new URL (assuming it's a cgi-script or a cgi-include). The other
> variables will exist only if they existed prior to the error/problem.
> None of these will be set if your ErrorDocument is an external redirect
> (anything starting with a scheme name like http:, even if it refers to
> the same host as the server)."
>
> I realize that the last bit of this quote applies directly to this
> situation, and is likely the reason for which using %{REQUEST_URI} does
> not work in this context. But if I remove the https scheme from the
> ErrorDocument directive, then this rule is no longer effective.
>
> Does anyone have any thoughts as to how I can meet all three requirements?
>
> Thanks for any help!
>
> -Ben
I managed to make this all work.
The solution has several parts:
1.)
http://stackoverflow.com/questions/2220167/do-http-authentication-over-https-with-url-rewriting/4900197#4900197
"
If you place the rewrite rules in the main config, outside any or or
similar, rewriting will be done before authentication.
see http://httpd.apache.org/docs/2.2/rewrite/rewrite_tech.html
"
So, I placed the following in the main server configuration:
# Force connections to occur via the specified domain.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^example.com
RewriteRule (.*) https://example.com%{REQUEST_URI} [R=301,L]
# Force SSL (while retaining the query string).
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
This had no effect for virtual hosts, which lead me to the next item.
2.) http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#vhosts :
"
By default, mod_rewrite configuration settings from the main server
context are not inherited by virtual hosts. To make the main server
settings apply to virtual hosts, you must place the following directives
in each <VirtualHost> section:
RewriteEngine On
RewriteOptions Inherit
"
So, I placed those directives at the top of the virtual host's
configuration, and the rewrite rules are indeed effective.
Now, whenever I request a URL over a plain-text connection, I am
redirected to the secure equivalent, *before authentication is
requested*, with the query string intact.
3.) As a fall-back, in the event that mod_rewrite is disabled or
misconfigured, I have the following:
<Location />
SSLOptions +StrictRequire
SSLRequireSSL
ErrorDocument 403 https://example.com
# Authentication directives go here.
</Location>
One caveat to using the ErrorDocument directive in this way is that if
SSL is disabled for any reason, the above block will produce a
never-ending redirect loop. Removing the ErrorDocument directive
mitigates that risk, but causes a user-unfriendly "403 Access denied"
message for plain-text connection attempts when SSL *is* enabled/working.
I hope this info is useful to others who may be attempting to achieve
the same.
Best regards,
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org