CloudFlare SSL與ASP.NET MVC的兼容性RequireHttps

Question

我在AppHarbor（使用Amazon EC2）上託管ASP.NET MVC 4站點，並且我正在使用CloudFlare進行靈活SSL。嘗試使用RequireHttps時，我遇到重定向循環（310）的問題。問題是，與EC2一樣，CloudFlare在將請求轉發到服務器之前終止SSL。但是，儘管Amazon設置了X-Forwarded-Proto標頭，以便您可以使用自定義過濾器處理請求，但CloudFlare似乎並未顯示。或者如果他們這樣做，我不知道他們是怎麼做的，因爲我無法攔截那個級別的流量。我已經嘗試了Amazon EC2的解決方案，但他們似乎沒有幫助CloudFlare。

有沒有人遇到過這個問題，或者對CloudFlare有足夠的瞭解？

Answer 1

的X-Forwarded-Proto頭故意AppHarbor的負載平衡器重寫該請求的實際方案。

注意的是，雖然CloudFlare的靈活SSL選項可能會增加稍多的安全性，仍然有未加密的流量行駛在公共互聯網從CloudFlare的到AppHarbor。這可以說是違背了SSL的目的，除了出現外，還減少了攻擊媒介的數量（比如用戶本地網絡上的數據包嗅探） - 也就是說，它對用戶而言可能看起來「專業」，但實際上它仍然不安全。

這並不理想，尤其是因爲AppHarbor既支持安裝自己的證書，也包括開箱即用的揹負式SSL。 CloudFlare還建議在原始服務器/服務支持SSL的情況下使用「完全SSL」。所以，你有兩個選擇：

• 繼續使用不安全的「靈活的SSL」選項，但不是在您的自定義過濾器RequireHttps檢查X-Forwarded-Proto頭，您應檢查CF-Visitor頭的scheme屬性。在this discussion有更多的細節。
• 使用「完整SSL」並將CloudFlare指向您的*.apphb.com主機名。這樣，您可以使用AppHarbor應用默認啓用的免費揹負式SSL。您必須覆蓋CloudFlare上的Host標題才能完成此工作，並且需要here's a blog post on how to do that。這當然會使您的應用的請求看起來像是對您的*.apphb.com域進行的 - 因此，如果您自動將請求重定向到「規範」網址或生成絕對網址，您可能必須考慮此問題。
• 上傳您的證書並將自定義主機名添加到AppHarbor。然後在CloudFlare上打開「完整SSL」。這樣主機頭將保持不變，您的應用程序將繼續工作而不做任何修改。您可以在this knowledge base article中閱讀更多關於AppHarbor提供的SSL選項的信息。

Answer 2

這很有趣。

只是我最近有一個討論，與我們的客戶，誰問我關於「靈活」 SSL和建議，我們（Incapsula）也提供這樣的選項之一。

經過一番討論後，我們都得出的結論，這樣的功能會產生誤導，因爲它會提供最終用戶提供安全的錯覺，同時也暴露了網站所有者的責任索賠。

簡而言之，訪問者在「靈活」SSL連接之一可能感覺絕對安全，並願意提供敏感數據，而不知道「服務器到雲」路由根本沒有加密，可以截獲（即通過後門外殼）。

有趣的是，在這裏訪問並看到其他人達到相同的結論。 +1

請注意，作爲網站所有者，您可能需要承擔此類設置可能導致的任何不必要的曝光。

我的建議是做負責任的事情，並投資於SSL證書，甚至創建一個自簽名的（用於加密'雲服務器'路線）。

Answer 3

或者您可以獲得由StartCom簽名的免費一年SSL證書並將其上傳到AppHarbor。

然後，你可以稱它爲一天，並在後面拍拍自己！這是直到將來你從現在開始購買證書=）。