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@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|