ここでの他の回答のほとんどはサイト全体のSSLの欠点に対処しているため（主にパフォーマンスの問題-これらは、SSL終端をSSLプロキシボックスまたはSSLカードにオフロードすることで簡単に軽減できます）、私は指摘しますSSL経由でログインページのみを使用してから非SSLに切り替えることに関するいくつかの問題：
- サイトの残りの部分は保護されていません（これは明らかですが、ユーザーのパスワードだけに重点が置かれている場合もあります）。
- ユーザーのセッションIDは平文で送信する必要があり、傍受して使用できるようにするため、悪意のあるユーザーがユーザーになりすますことができます。 （これは主に Firesheep hubbubについてのものです）。
- 前のポイントのため、セッションCookieを
secure属性でマークすることはできません。つまり、追加の方法で取得できるということです。 - ログインのみのSSLを使用したサイトを見たことがありますが、もちろん、パスワードを忘れたページ、パスワードを変更したページ、さらには登録ページまで含めないでください...
- SSLから非SSLへの切り替えは多くの場合複雑であり、ウェブサーバーで複雑な設定が必要になる場合があり、多くの場合、ユーザーに恐ろしいメッセージが表示されます。
- ログインページのみの場合、f.e。あなたのサイトのホームページからログインページへのリンクがあります-誰かがあなたのホームページを偽装/変更/傍受しないことを保証し、別のログインページを指すようにするにはどうすればよいですか？
- 次に、ログインページ自体がSSLではなく、[〜＃〜] submit [〜＃〜]のみである場合があります-それはパスワードが送信されるのはこのときだけなので、安全でしょうか？しかし、実際には、ユーザーから、パスワードが手遅れになるまで、正しいサイトに送信されていることを事前に確認する機能がなくなります。 （例：バンクオブアメリカ、その他多数）。
重要な「欠点」として増加する「サーバーのオーバーヘッド」は一般的な神話です。 Googleエンジニア 注記 gmailを100％SSLに切り替えたときに、追加のハードウェアは導入されておらず、SSLはCPU負荷の1％未満の増加とネットワークトラフィックの2％の増加しか占めていませんでした。スタックオーバーフローには、これに対処するためのいくつかの質問もあります： SSLが課すオーバーヘッドの量？ および HTTPとHTTPSのパフォーマンス 。
Zscalerブログエントリから WebがまだSSLのみに切り替えられていないのはなぜですか？
「セッションサイドジャッキングの問題がFiresheepによってもう一度強調されたため、多くの人から、ウェブサイト、または少なくとも主要プレイヤー（Google、Facebook、Amazonなど）がすべての通信でデフォルトでSSLを有効にしていない理由を尋ねられました。暗号化は、オープンワイヤレスネットワークでユーザーセッションを簡単に盗聴できないようにする唯一の方法です。
これは簡単に聞こえます-URLのhttpの後にsを追加するだけです！実際、それほど簡単ではありません。ここにいくつかの課題があります。」
課題の概要（短所）：
- 「サーバーのオーバーヘッド」
- 「待ち時間の増加」
- 「CDNの課題」
- 「ワイルドカード証明書では不十分」
- 「混合HTTP/HTTPS：ニワトリと卵の問題」
- 「警告は怖い！」
Ars Technicaは 優れた記事 をサイト全体にSSLを展開する際の課題のいくつかを説明しています。
1つの大きな問題：ほとんどの広告ネットワークは、SSL経由で広告を配信する方法を提供していません。さらに、HTTPSを介して配信されるメインページに（HTTPを介して配信される）広告を埋め込むと、ブラウザーは恐ろしい混合コンテンツの警告を発行します。したがって、広告がサポートされているサイトでは、サイト全体でSSLに移行することが非常に困難になる可能性があります。
この記事では、サードパーティのウィジェット、分析、埋め込み動画など、その他の課題についても概説しています。
OK、これは古代の質問ですので、私の答えはおそらくここの下部にあるだろう。しかし、私は「短所」側に追加するものがあります。
HTTPSレイテンシ：
クライアントからサーバーへのHTTPレイテンシを低くすることは、 高速読み込み、応答性の高いWebサイト を作成するために重要です。そして ページの読み込み時間が短いとエンドユーザーの幸せが増します 。
TCP/IPだけでも有名なTCP 3ウェイハンドシェイク、つまりプレーンHTTPの初期接続セットアップTCPには3パケットが必要です。SSL/ TLSが使用すると、接続設定はより複雑になります。つまり、プレーンテキストHTTPよりも 新しいHTTPS接続のレイテンシは避けられないほど高くなります です。
この影響は、HTTPS接続を何度も再利用することで（つまり、永続的な接続を使用することで）減らすことができます（ただし排除はできません）、およびその他の SSL False Startなどのパフォーマンスの最適化 。
すべての最新のブラウザ HTTPオブジェクトを並行してダウンロード 可能な場合はいつでもできるため、ページの読み込みが遅くなるHTTPSの正確なモデリングは複雑です。それでも、現在のテクノロジーでは、初期接続セットアップ時間が長くなることは重要であり、避けられません。したがって、新しい接続遅延の増加は重要な考慮事項です。
上記の他の回答で見逃されている欠点は、最近のコンテンツ配信ネットワーク（Akamaiなど）への依存度が高いことです。現在の使用状況の多くのWebページは、さまざまなドメインからコンテンツを取得するため、ブラウザーはそれぞれの証明書を必要とします。または警告がポップアップします。そしてもちろん、攻撃者がブラウザがすでに証明書を持っているCDNプラットフォームを使用した場合、必要なときに警告を受け取れない可能性があります。
アプリケーションとコンテンツの現在の配信方法に関するトリッキーな問題。
長所は間違いなくセキュリティが向上しています。短所は、比較的遅い接続、より集中的なCPU使用率、正確な証明書管理の必要性、証明書のコスト（自己署名証明書を使用しない場合）です。しかし、最近では、httpsを使用する習慣が広まり、エンドユーザーにとってのメリットと、サービスを提供している会社への信頼が高まったため、これらの短所が背景に浮かび上がってきました。
他の回答では、HTTP-> HTTPSの移行を困難にする混合コンテンツの警告が原因で、「鶏/卵の問題」が発生したと主張しています。それは問題ではありますが、彼らがそうするほど難しくはないと思います。
混合コンテンツは protocol-relative URLs と、XSSの問題を見つけるために使用するのと同じスキャナーを使用して対処できます。
RFC 3986セクション4.2 network-path referenceという用語を使用します。
2つのスラッシュ文字で始まる相対参照は、ネットワークパス参照と呼ばれます。
まず、同じ起源のリンク、画像、その他のサイトアセットでhttp://example.com/の使用がすべて見つかるまでページをスキャンし、プロトコル相対URL（//example.com/...）に置き換えます。これにより、HTTPとHTTPSのどちらを介してページを提供するかに関係なく、同じHTMLを提供できるようになり、移行の後半で問題が発生した場合にロールバックするのにはるかに有利な立場になります。
次に、恒久的なHTTP-> HTTPSリダイレクトを設定して、制御外のサイトの既存のURLが引き続き機能し、HTTPS経由でのサービスを開始するようにします。積極的なキャッシュヘッダーで永続的なリダイレクトを使用すると、検索エンジンがページランクを転送し、再訪問者のサイトを高速化できます。
もちろん、スキャナーが混合コンテンツを探し続けるようにして、リグレッションをキャッチする必要があります。
これは古い質問/スレッドであることはわかっていますが、サイドサイドSSLを実行するための巨大なPROを指摘したかっただけです。
SPDY
Apacheでmod_spdyを使用するには、SSLが必要です。
まだSPDYをデプロイしていません。完了してください！ ChromeとFirefoxの両方がプロトコルとOperaをサポートしています。
これは、SPDYを利用できるユーザーの約半分です。
他の欠点（他の人が触れた）は、明らかに速度に影響を与えるキャッシュの欠如です。また、HTTP_FORWARDED_FORなど、一部のサーバー変数は使用できないと思います。
ここで述べたすべての良い点は、しかし、私は詐欺のコストをミスしています！そしてコストによって、私は証明書を購入するだけでなく、証明書、失効、WebサーバーのCPU負荷を減らすための専用の暗号化モジュールを管理するための適切なインフラストラクチャを持っていることを意味します。
サイト全体を暗号化しておく利点：
- ログイン後にプレーンテキストを送信することで、プライバシーが懸念される訪問者を怒らせることはありません。
- サイトのhttp部分とhttps部分の間でリダイレクト/リンクする際のミスのリスクが少なくなります。
短所：？
グーグルなどからの声を読んでください。 100％httpsを実行するのにコストがかかる必要はありません。
WebサイトがCMSによって管理されており、技術者以外のユーザーがページの編集に使用できる場合、HTMLを編集して、HTTPなどの画像などのオフサイトリソースへの参照を含めることができます。必要な場合にのみSSLを使用し、他のページをHTTPにリダイレクトするショッピングサイトを構築しました。そうしないと、所有者がサイトにスタックしているすべてのオフサイト画像が原因で混合コンテンツの警告が表示されます。