HTTPからHTTPSへの投稿は悪い習慣ですか？
SSLがデータの暗号化との両方で機能し、IDとWebサイトの正当性、HTTPSに投稿する場合でも、HTTP経由で要求されたページにログオンフォームを提供することは避けるべきですか？
この質問は、私が昨日投稿した パスワードの習慣がおかしい人 と、認証前にブラウザに表示されている証明書を目に見えなくても、フォームが安全に投稿されていれば問題ないことを示唆するフィードバックに関するものです。 。
私の考えでは、資格情報を引き渡す前にサイトの正当性を検証する能力を失うだけでなく、それが確実であるとは限らないため、SSLは短期間で販売されますisHTTPS経由の投稿。私はTwitterやFacebookのようなものがこのアプローチを取ることを意識していますが、彼らはそうするべきですか？私はここで何かを見落としているのですか、これは推奨されない習慣ですか？
更新：私はこの質問の結果とブログ記事でのその後の議論の詳細をまとめました SSLは暗号化についてではありません
OWASPの状態：
（ http://www.owasp.org/index.php/SSL_Best_Practices から逐語的にコピー）
安全なログインページ
ログインページを安全に設計するには、いくつかの重要な考慮事項があります。次のテキストでは、SSLに関する考慮事項について説明します。ログインはSSLページに投稿する必要がありますこれはかなり明白です。ユーザー名とパスワードは、SSL接続を介して投稿する必要があります。フォームのアクション要素を見ると、httpsであるはずです。
ログインランディングページはSSLを使用する必要がありますユーザーがフォームに入力する実際のページはHTTPSページである必要があります。そうでない場合、攻撃者はユーザーに送信されるときにページを変更し、フォーム送信場所を変更するか、入力されたユーザー名/パスワードを盗むJavaScriptを挿入する可能性があります。
SSLエラーまたは警告メッセージがあってはなりませんSSL警告メッセージの存在は失敗です。これらのエラーメッセージの一部は、正当なセキュリティ上の問題です。他のユーザーは、ユーザーが盲目的に[同意する]をクリックするため、実際のセキュリティの問題に対してユーザーを鈍感にします。 SSLエラーメッセージの存在は受け入れられません-wwwのドメイン名の不一致でも。
HTTP接続をドロップする必要がありますユーザーがログインページのHTTPバージョンに接続しようとすると、接続が拒否されます。 1つの戦略は、HTTP接続をHTTPS接続に自動的にリダイレクトすることです。これによりユーザーは安全なページに移動しますが、リスクが1つ残っています。攻撃者が中間者攻撃を実行すると、HTTPリダイレクト応答を傍受し、ユーザーを別のページに送る可能性があります。
繰り返します：ログインランディングページはSSLを使用する必要があります
OWASPのベストプラクティスで述べられていることを正確に行うための 自動化されたツール があることを追加する価値があるかもしれません。 「このリンクには、攻撃に関するBlack Hatのプレゼンテーションが含まれています。
すでに提供されている回答に追加します。 HTTPS以外のランディングページを使用すると、攻撃者がサイトを変更し、ユーザーの認証情報を取得できるという実際的なケースがあります。 この例 は、私が見た最新のものです。この場合、それはISPレベルで行われましたが、同様に、ワイヤレスホットスポットプロバイダーまたは関連ツールを使用してMan-In-The-Middle攻撃を実行するすべての人が行うことができました。