Apache：安全でないポートに送信された安全でないリクエスト…リダイレクトしたい

序文

まず、単純なポート80->ポート443リライトはこれを修正しません。以前のほとんどすべての質問、メールスレッド、フォーラムスレッドなどで、これが最初の無知な応答であり、何度もオウムされたことがわかりました。

第二に：はい、同じポートでHTTPトラフィックとHTTPSトラフィックを処理することはできません。 これはそうではありません。

シナリオ：

ポート乗算を介して複数のサイトをホストするApacheサーバー。ポート80は公開サイトとして機能します。ポート443は、そのサイトの安全なバージョンを提供します。

ポート7443、8443、および9443はそれぞれ、SSLで保護された個別のサイトに対応します。

ユーザーがURLを誤って入力した場合、または無効なリンク（http：//hostname.tld：7443など）が表示された場合、次のようなばかげたページが表示されます。

Apache Bad Requestエラーメッセージ

サーバーの代わりに、それらをhttps：//hostname.tld：7443にリダイレクトするだけです。

私の質問は、Zeusの尻の名の下に、Apacheの動作またはこのエラーメッセージをどのように変更して、ユーザーを自動的にリダイレクトできるかということです。

Apacheは、HTTPS用に構成されていても、明らかに（そのエラーメッセージを表示するために）非httpsリクエストを処理しています。デフォルトでリダイレクトを実行するだけでなく、私には非常に馬鹿げているように見えますが、同意しなくても、なぜ彼らがそうした動作を行ったのか理解できます。だから私の質問です：それを変更できますか？彼らはエラーSOMEWHEREを処理しており、Apacheが実際の構成の宝庫なので、この動作を処理するディレクティブがどこかにあるのは当然のことですが、今のところ数時間いじってみることで見つけることができませんでした。

更新：

私は次のようなさまざまなことを試みました：

ErrorDocument 400ディレクティブを使用してStatus 301、Locationヘッダーとヘッダーを送信するだけのCGIおよびPHPスクリプトを取得します。これにより、空白のページになります。ErrorDocument 400 https://hostname.tld:7443単に使用すると、そのリンクがページに表示されます。
mod_rewrite私またはGoogleのほとんどすべての組み合わせを使用すると、サイト全体を指示する包括的な声明を含め、思いつく可能性があります。これらは機能しません。文字通り、彼らは何もしません。Apacheが書き換えディレクティブの処理を試みる前に、上記のエラーを引き起こしているのではないかと思います。

カスタムポートを使用しているため、ポートベースのリダイレクトを使用できません。スクリプトベースのリダイレクトは、http / httpsの不一致のために配信されないため、使用できません。私はこれをバグや意図しない動作にまで踏み込んでいくつもりですが、誰かが非常にカスタムエラーメッセージをそこに入れることを予見していました。彼らがすでに提供している URL は？

— ピールマン
ソース

単一のポートでsslとnon-sslの両方について受け入れられた回答を参照してください

— DanielVérité

ダニエル、それは私が見つけた多くの質問の1つであり、この質問を投稿する前に私が試みた解決策でした。問題はPHPコンポーネントにあると思いますが、@ hruntingの回答の更新は今のところ私にとっては問題なく機能しているので、すでに持っている以上の時間を費やすことはしません。少なくとも私がするまでは。

— ピールマン2013

リンクされたビデオに賛成票を投じると、私の感情が完全に

— 伝わります

回答:

これはおそらく、Apache 2.2以下がこの特定の状況を処理する方法のバグだと思います。

SSL読み取り400 Bad Requestエラーの場合、Apache 2.2はHTTP応答コードまたはヘッダーを返さず、HTTP応答本体のみを返します。私はポート443にTelnet接続して送信することでテストします。

GET / HTTP/1.1

サーバーはすぐに戻ります（私にとって）：

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://server.tld/"><b>https://server.tld/</b></a></blockquote></p>
</body></html>

HTTP応答コードまたはHTTPヘッダーがないことに注意してください。

これをApache 2.4サーバーに対して行うと、次のようになります。

HTTP/1.1 400 Bad Request
Date: Sun, 10 Feb 2013 00:47:23 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0g
Content-Length: 462
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<hr>
<address>Apache/2.4.3 (Unix) OpenSSL/1.0.0g Server at server.tld Port 443</address>
</body></html>

あなたがしたようにErrorDocument行を設定した場合：

ErrorDocument 400 https://server.tld/

次に、302リダイレクトのHTMLを取得しますが、ヘッダーは1つもありません。302リダイレクト応答コードとLocation:ヘッダーがないと、ブラウザーはリダイレクトしません。

Apache 2.4にアップグレードして、動作するかどうかを確認してください。私は少なくともApache 2.4.3でテストおよび確認しましたが、これが動作が更新された時期を正確に見つける努力はしていません。彼らが2.4を準備している大量の作業で、彼らは副作用として望ましくない動作を修正したのではないかと思います。

関連するApache httpdバグ：

44907
50823

更新

スクリプトにヘッダー（クライアントに送信されない）を出力させ、必要なヘッダーを手動で出力することで、バグのあるApacheに強制的に希望の動作（リダイレクト）を与えることができます。Apache 2.2.22で動作する基本的なPerlスクリプトは次のとおりです。

#!/usr/bin/perl

use strict;
use CGI;

my $q = CGI->new();

# this will cause Apache to handle the response properly, but is meaningless otherwise
print $q->redirect("https://localhost/");

# this actually performs the redirect
print "HTTP/1.1 302 Found\r\n";
print "Location: https://localhost/\r\n";
print "\r\n";

# you can do whatever you want here; this will be the HTML body

SSLなしでSSLポートと通信するだけでなく、400が生成される理由は他にもあることに注意してください。これを判別する簡単な方法は、HTTPS環境変数を探すことです。これが設定されている場合、SSLは適切にネゴシエートされ、他の何かが400を引き起こしています（その場合、ダブルヘッダートリックを実行しないでください）。HTTPSが設定されていない場合は、上記のようにリダイレクトを返します。

— 走る
ソース

聖なる。くだらない。完璧な答え。グラシアス。

— ピールマン、2013

ご存知のように、私はこれを読んだときに、「Apache 2.2を使用していて、この種のリダイレクト動作が必要な場合は本当にうんざりだ」と私は思います。私は、Ubuntuシステムに適切なApache 2.4 debを見つける（または自分で作成する）作業はしません。PHPスクリプトからソリューションをハックできると思います。Apacheは明らかにクライアントに出力をダンプするだけなので、期待される特定のコンテンツを返す場合、Apacheをアップグレードしなくても、探している動作を得ることができると思います。PHPスクリプトで「HTTP / 1.1 302 Found \ r \ nLocation：server.tld \ r \ n \ r \ n」を出力してみてください。

— 2013

問題は、PHPスクリプトが処理されているように見えないことです。これは現在、Ubuntu Server 12.04上のApache 2.2.22にあることに注意してください。そして、はい、それは本当に、本当に最悪です。特にこれらのバグレポートで、リダイレクトを自動的に行うオプションを提供することさえ完全に拒否されているように見える場合、2.2が修正されることはあまり期待されていないようです。

— ピールマン2013

そして、私が上で述べたように、安全にリダイレクトするのではなく、なぜそのエラーメッセージを書くのにトラブルを経験するのか私には意味がありません（真剣に、なぜリダイレクトしないのですか？それは悪い考えだと思います）。

— ピールマン2013

私はファイルシステム全体をgrepして、その流血のメッセージのテキストを探して、どこからメッセージが届いているのかを確認しました。たまたま、<javascriptタグを挿入して、ハッキングリダイレクトで幸運になるかもしれませんが、これまでのところ、サイコロ。これについては、他の点ではかなり厳格なApacheの

— 素晴らしさに

-1

これはmod-rewriteで修正できます。何にでも一致するルールを設定します。Stackoverflowでこの回答を参照してください

— トレント
ソース

いいえ、すでに試してみましたが、機能しません。最初にhttp / httpsの不一致にぶつかるので、ModRewriteステップに到達することすらありません。

— ピールマン2013

HRM私はあなたがあなたの上からapacheの設定ファイルを開始し、それが呼び出しているかを見るためにダウンあなたの方法を働いていると仮定して

— トレント

私は実質的にsites-availableディレクトリ全体を記憶しました。単にナンセンスにリダイレクトしたり、別のサイト、別のポートなどにリダイレクトしたりしても、その400 Bad Requestをロードし続けるだけです。

— ピールマン2013