httpをhttpsにリダイレクトするのは悪い考えですか？
このページ を読んでいますが、サイトがSSLで、ユーザーが通常のhttpを介してアクセスしようとすると、アプリケーションはユーザーをhttpsにリダイレクトすべきではありません。彼をブロックするだけです。誰かがこれの有効性を検証できますか？それは良い考えのように聞こえません、そして、ユーザーをhttpsに転送することの本当のリスクは何なのでしょうか。その背後には技術的な理由はなく、ユーザーを教育するのに良い方法であるようです。
ドメインへのHTTPアクセスを無効にします。SSLへのリダイレクトやリンクも行いません。このウェブサイトはHTTP経由ではアクセスできないため、ユーザーはSSL経由でアクセスする必要があることをユーザーに通知してください。
これは、MITMおよびフィッシング攻撃に対するベストプラクティスです。これにより、ユーザーはHTTPを介してアプリケーションにアクセスすることはできず、フィッシング攻撃やMITM攻撃に遭遇すると、何かがおかしいことがわかります。
アプリケーションをMITM攻撃およびフィッシング攻撃から保護する最良の方法の1つは、ユーザーを教育することです。
セッションID Cookieを含むHTTP要求は、セッションハイジャック攻撃の対象となります。 HTTPを許可してHTTPSにリダイレクトする場合、そのCookieがセキュアとしてマークされることが重要です。
HTTPを完全にブロックする必要がある技術的な理由もわかりません。多くのサイトはHTTPをHTTPSに転送します。これを行う場合、ブラウザがHTTPS接続のみを使用することを宣言するWebセキュリティメカニズムであるHTTP Strict Transport Security（HSTS）を実装することを強くお勧めします。
HSTSは、Strict-Transport-Security: max-age=31536000などの応答ヘッダーを指定することにより実装されます。準拠するユーザーエージェントは、安全でないリンクを自動的に安全なリンクに変え、中間者攻撃のリスクを減らします。さらに、証明書が安全でないリスクがある場合、例えばルート認証局が認識されない場合、エラーメッセージが表示され、応答は表示されません。
HTTPからHTTPSへのリダイレクトに関する技術的なリスクはありません（回答の最後にあるアップデートのリスクを除く）。たとえば、Gmailおよびyahooメールがそれを行っています。 HTTPデバッグツール（Fiddlerなど）を使用すると、サーバーから返された302リダイレクト応答を明確に確認できます。
ユーザビリティの観点から見ると、ブロッキングは悪い考えだと思います。多くの場合、ユーザーはHTTPまたはHTTPSを指定せずにブラウザーにアドレスを入力しています。たとえば、「mail.google.com」と入力してGmailにアクセスします。デフォルトでは「http://mail.google.com」になり、自動的に「https://mail.google.com」にリダイレクトされます。自動リダイレクトなしでは、常に完全なアドレスを入力する必要があります。
HTTPSはMITM攻撃に対する最善の方法であるという引用記事に同意しますが、フィッシングに対するベストプラクティスであることに同意しません。実際、ユーザー教育はフィッシング攻撃に対する重要な要素です（ユーザーは正しいドメインからサイトにアクセスしていることを確認する必要があります）が、HTTPからHTTPSへのリダイレクトをブロックして教育を行うことはできません。
更新 @Pedroと@Spoltoは正しい。機密性の高いCookie（セッションCookieや認証Cookieなど）に関連する特別な注意を払う必要があります。これらは実際にHTTPS経由でのみ送信されるように、安全とマークする必要があります。私はそれを見逃しました。両方とも+1。
この質問に気付いたばかりですが、同様の質問に対する回答をいくつか書いています。
HTTPからHTTPSへのリダイレクトは必ずしも有害ではないと思いますが、これは慎重に行う必要があります。重要なのは、開発段階でこれらの自動リダイレクトが存在することに頼るべきではないということです。せいぜい自分でブラウザにアドレスを入力するユーザーに使用するべきです。
また、HTTPSを使用していること（および証明書が警告なしで検証されていること）を期待するときに確認するのは、ユーザーの責任です。
HTTPからHTTPSに切り替える実際のリスクは、セッションを維持することを選択した場合、切り替え前に行われたことを確実に信頼できることです。ウェブサイトのフローとプロセスでは、これを考慮に入れる必要があります。
たとえば、ユーザーがショッピングサイトを閲覧し、HTTPを使用してさまざまな商品をカートに追加し、HTTPSを使用して支払いの詳細を取得する予定がある場合は、HTTPSを使用してバスケットの内容を確認する必要もあります。
さらに、HTTPからHTTPSに切り替える場合、ユーザーを再認証し、プレーンHTTPセッション識別子がある場合はそれを破棄する必要があります。そうしないと、攻撃者がそのCookieを使用してサイトのHTTPSセクションに移動し、正当なユーザーになりすます可能性があります。
技術的な観点から、IMOはHTTPSが取るもの以外に副作用はありません。
UX/UIの観点からは、クリックスルーまたは遅延リダイレクトを使用することをお勧めします。リダイレクト自体はMITM攻撃の影響を受けるため、最初にHTTPS URLを入力するように視覚的に表示します。ただし、多くのHTTPS Webサイトがこれを行うわけではありません。これは、HTTPSページでブラウザのロックアイコンを探すように求めるビジュアルを提供するためです。
これは完全に受け入れ可能な「ブートストラップ」メソッドです。301HTTPからHTTPSへリダイレクトし、HTTPS側でブラウザーをHTTPSにロックするためにStrict-Transport-Securityヘッダーを返します。
ブラウザがHSTSをサポートし、ブラウザキャッシュまたはプリロードリストのいずれかにHSTSトークンが見つからない限り、Webブラウザはプロトコル指定子なしでURLを入力するとHTTPプロトコルを試行するため、HTTPを完全にブロックすることは大きな使いやすさの問題になります。