我正在閱讀this page，它說如果一個網站是SSL並且用戶試圖通過普通的http訪問它，應用程序就不應該將用戶重定向到https。它應該阻止他。有人可以驗證這個的有效性嗎？這聽起來不是一個好主意，我想知道將用戶轉發到https的真正風險是什麼。它似乎沒有背後的技術原因，只是這是教育用戶的好方法。將http重定向到https是一個壞主意？
禁用對域的HTTP訪問， 甚至不重定向或將其鏈接到SSL。 只是通知用戶這個網站是 不能通過HTTP訪問，他們有 通過SSL訪問它。
這是針對MITM 和phising攻擊的最佳做法。這樣你的 用戶將被教育， 應用程序永遠不能通過HTTP 訪問，當他們遇到了一個phishing 或MITM攻擊他們將知道 有些事情是錯誤的。
一來保護您的 應用對MITM攻擊和 網絡釣魚攻擊的最佳方法是教育你的 用戶。
從HTTP重定向到HTTPS，我沒有看到任何技術風險（除了我的答案更新中的更新）。例如，Gmail和雅虎郵件正在這樣做。您可以使用HTTP調試工具（如Fiddler）來檢查，您可以清楚地知道服務器返回的302重定向響應。
我相信從可用性的角度來看，阻塞是一個壞主意。很多時候，用戶在瀏覽器中輸入地址而不指定HTTP或HTTPS。例如，我通過輸入「mail.google.com」訪問Gmail，默認爲「http://mail.google.com」，並自動重定向到「https://mail.google.com」。如果沒有自動重定向，我將始終輸入完整的地址。
我同意所引用的文章，HTTPS是最好的反對MITM攻擊的方法，但我不同意這是針對phising的最佳做法。用戶教育確實是防止網絡釣魚攻擊的關鍵因素（用戶必須檢查他們是否從正確的域訪問網站），但絕不會阻止HTTP重定向到HTTPS。
更新 @Pedro和@Spolto是正確的。必須特別注意與敏感cookie（如會話或認證cookie）有關的信息，這些cookie確實應該標記爲安全，以便它們只能通過HTTPS傳輸。我錯過了那一個。 +1你們倆。
從技術角度來看，除了HTTPS採取的措施之外，IMO沒有副作用。
從UX/UI的角度來看，建議使用點擊或延遲重定向，因爲重定向本身受到MITM攻擊，所以建議您首先要求用戶輸入HTTPS URL。但是，很多HTTPS網站都是這樣做的，因爲它們提供視覺效果，要求用戶在其HTTPS頁面上查找瀏覽器上的鎖定圖標。
包含會話ID cookie的HTTP請求會受到會話劫持攻擊。重要的是，如果您確實允許HTTP並重定向到HTTPS，則該Cookie將被標記爲安全。
我看不出有任何技術原因，HTTP需要要麼被完全阻斷，許多網站做向前HTTP到HTTPS。當這樣做時，強烈建議實施HTTP Strict Transport Security（HSTS），它是一種網絡安全機制，它聲明瀏覽器只使用HTTPS連接。
HSTS是通過指定一個響應報頭如Strict-Transport-Security: max-age=31536000實現。遵守用戶代理會自動將不安全的鏈接變成安全鏈接，從而降低中間人攻擊的風險。此外，如果存在證書不安全的風險，例如根權限不被識別，則顯示錯誤消息並且不顯示響應。
+1。會考慮在整個重定向過程中持續存在的會話cookie可能被認爲是受到威脅的。通常，網站會使原始Cookie無效，並創建一個用於HTTPS流量的新網站（良好的網站也會啓用安全cookie標記）。 – 2010-12-06 10:51:35
如果您要提供「安全」服務，請始終在會話cookie中使用「安全」標誌！ – 2010-12-06 11:49:54
從HTTP到HTTPS實際上是一個不太好的主意。例如，攻擊者可以使用類似ssl strip這樣的工具進行中間人攻擊。 要解決此問題，您應該使用HSTS protocol。它受到所有主流瀏覽器的支持（Internet Explorer是最新的採用者，從IE12開始支持它），並被許多頂級網站（例如Paypal，Google）使用。
我剛剛注意到了這個問題，但我已經寫了幾個答案，以類似的問題：
我不認爲從重定向HTTP到HTTPS是有害的，但這應該做得很好。重要的是，在開發階段不應該依賴這些自動重定向。最多隻能用於在瀏覽器中輸入地址的用戶。
它也完全由用戶負責檢查比他們使用HTTPS（和證書沒有任何警告驗證）時，他們期望它。
從HTTP切換到HTTPS的實際風險是，你可以可靠地信任什麼開關之前完成，如果您選擇保留該會話。您網站的流程和流程應該考慮到這一點。例如，如果您的用戶瀏覽您的購物網站並使用HTTP將各種商品添加到購物車中，並且您計劃使用HTTPS獲取付款明細，則還應讓用戶使用HTTPS確認其購物籃的內容。
另外，從HTTP到HTTPS切換時，可能必須重新認證用戶並丟棄普通HTTP會話標識符，如果有的話。否則，攻擊者可能能夠使用該cookie移動到該網站的HTTPS部分，並潛在冒充合法用戶。
這是一個完全可以接受的「引導」的方法 - 301 HTTP重定向到HTTPS然後在HTTPS側，以鎖定瀏覽器到HTTPS返回嚴格，運輸安全頭。
這將是一個主要的可用性問題，完全阻止HTTP，因爲Web瀏覽器會在沒有協議標識符的情況下輸入URL時嘗試使用HTTP協議，除非瀏覽器支持HSTS並且在瀏覽器緩存中找到HSTS令牌或預加載列表。
重定向不應該在應用程序未使用cookie時激活安全標誌，攻擊者可以在不安全的請求中捕獲cookie。 – 2010-12-06 11:51:51