AppHarbor (Amazon EC2 を使用) で ASP.NET MVC 4 サイトをホストしており、Flexible SSL に CloudFlare を使用しています。RequireHttps を使用しようとすると、リダイレクト ループ (310) の問題が発生します。問題は、EC2 と同様に、CloudFlare がリクエストをサーバーに転送する前に SSL を終了することです。ただし、Amazon はカスタム フィルターでリクエストを処理できるように X-Forwarded-Proto ヘッダーを設定しますが、CloudFlare は表示されません。もしそうなら、私はそのレベルでトラフィックを傍受できないため、彼らがどのようにそれを行っているのかわかりません. Amazon EC2 のソリューションを試しましたが、CloudFlare では役に立たないようです。
この問題を経験した人、または CloudFlare について十分に知っている人はいますか?
ヘッダーは、X-Forwarded-ProtoAppHarbor のロード バランサーによって意図的にリクエストの実際のスキームにオーバーライドされます。
CloudFlare の柔軟な SSL オプションによってセキュリティが少し強化される可能性がありますが、パブリック インターネットを介して CloudFlare から AppHarbor に移動する暗号化されていないトラフィックがまだあることに注意してください。これは、見かけ上、攻撃ベクトル (ユーザーのローカル ネットワークでのパケット スニッフィングなど) の数を減らすこと以外の点で、SSL の目的に反していることは間違いありません。つまり、ユーザーには「プロフェッショナル」に見えるかもしれませんが、実際にはまだ安全ではありません。
特に、AppHarbor は独自の証明書のインストールをサポートし、すぐに使用できるピギーバック SSL が含まれているため、これは理想的とは言えません。CloudFlare は、オリジン サーバー/サービスが SSL をサポートするシナリオでは、「フル SSL」を使用することもお勧めします。したがって、いくつかのオプションがあります。
X-Forwarded-Protoますが、カスタムRequireHttpsフィルターでヘッダーを検査する代わりに、ヘッダーのscheme属性を検査する必要がありますCF-Visitor。詳細については、このディスカッションを参照してください。*.apphb.comホスト名に向けます。このようにして、AppHarbor アプリでデフォルトで有効になっている無料のピギーバック SSL を使用できます。Hostこれを機能させるには、CloudFlareのヘッダーをオーバーライドする必要があります。その方法については、ブログ記事をご覧ください。もちろん、これにより、アプリへのリクエストが*.apphb.comドメインに対して行われたかのように表示されます。たとえば、リクエストを「正規の」URL に自動的にリダイレクトしたり、絶対 URL を生成したりする場合は、これを考慮する必要があります。これは面白い。
つい最近、クライアントの 1 人と話し合ったところ、「柔軟な」SSL について尋ねられ、私たち (Incapsula) もそのようなオプションを提供することを提案されました。
議論の末、このような機能は誤解を招く可能性があるという結論に達しました。これは、エンド ユーザーに誤った安心感を与えると同時に、サイトの所有者に賠償責任を負わせることになるからです。
簡単に言えば、「柔軟な」SSL 接続の 1 つを使用している訪問者は、暗号化の背後で完全に安全であると感じ、「サーバーからクラウドへ」のルートがまったく暗号化されておらず、傍受される可能性があることを知らずに、機密データを喜んで提供する可能性があります (つまり、バックドア シェル)。
ここを訪れて、他の人が同じ結論に達しているのを見るのは興味深いことでした。+1
ウェブサイトの所有者として、そのような設定が引き起こす可能性のある望ましくない露出に対して責任を負う可能性があることを知っておいてください.
私の提案は、責任あることを行い、SSL証明書に投資するか、自己署名証明書を作成することです（「クラウドからサーバーへ」ルートの暗号化に使用します）。