web-dev-qa-db-ja.com

SSLは安全ですか?

WebサイトのSSL証明書を取得し、SSLで保護された接続(HTTPS)を使用している場合、これはログインとパスワードのデータを送信するのに十分安全ですか、それとも暗号化またはハッシュを追加する必要がありますか?

また、SSLは中間者攻撃に対してどの程度安全ですか? HTTPSで送受信されたデータを取得または変更できますか?

そして、GETとPOSTはどうですか?どちらも暗号化されていますか、それともサーバーの回答が暗号化されているだけですか、それとも何もありませんか?

私はウィキペディアを読み、SSLとHTTPSに関する多くのGoogleの結果を読みましたが、実際にはわかりません。 SSLとHTTPSの安全性を理解できるように、私の質問に簡単に答えていただければ幸いです。

26
ReeCube

HTTPS動作の原理

HTTPプロトコルはTCPの上に構築されています。 TCPは、データが配信されること、または配信できないことを保証します(ターゲットに到達できないなど)。TCP接続を開いてHTTPを送信しますそれを介してメッセージ。

ただし、TCPはセキュリティレベルを保証しません。したがって、SSLという名前の中間層がTCPとHTTPの間に配置され、いわゆるHTTPSを取得します。この方法で作業の流れはトンネリングと呼ばれます-(SSL)トンネルの一端にデータをダンプし、それを他端で収集します。SSLはHTTPメッセージを取得し、それらを暗号化し、TCPを介して送信し、再度復号化します暗号化により、盗聴や透過的なMITM攻撃から保護されます(メッセージを改ざんします)。

しかし、SSLは暗号化を提供するだけでなく、認証も提供します。サーバーには、既知の証明機関(CA)によって署名された証明書が必要です。認証がなければ、MITM攻撃が依然として可能であるため、暗号化は役に立ちません。攻撃者はあなたをだまして、彼があなたが接続したいサーバーであると思わせる可能性があります。悪魔とのプライベートチャットはあなたが望むものではありません。接続しているサーバーが本当に接続したいサーバーであることを確認したいのです。 認証によりMITMから保護されます。

弱点

では、弱点はどこですか?

  • 安全な接続のエンドポイント。転送は安全かもしれませんが、サーバー自体はどうですか?またはクライアント?彼らはそうしないかもしれません。
  • HTTPSを使用しません。ユーザーは、さまざまな方法でスキームを使用しないようにだまされる可能性があります。
  • 信頼できないCA。それらは認証部分を破壊し、MITM攻撃を可能にします。
  • 弱い暗号化メカニズム。暗号化技術は2つの方法で老朽化します。設計に深刻な欠陥が見つかり、ブルートフォースよりもはるかに効率的な攻撃につながる可能性があります。または、ムーアの法則によるパラメータと処理能力の増加により、ブルートフォース攻撃が可能になる場合があります。
  • スキームの実装。まあ、Aを指定してBを実装すると、AのプロパティがBに適用されない場合があります。

直接回答

  • SSLを使用して転送をセキュリティで保護したと言っているようです。これだけでは不十分です。サーバーのセキュリティが危険にさらされる可能性があります。パスワードをプレーンテキストで保存したり、ハッシュ形式を使用したり、saltを追加したりしないでください。

  • SSLは、送信時と受信時の両方でデータを暗号化します。 MITM攻撃は、攻撃者がクライアントが信頼する機関によって署名された証明書を持っている場合にのみ実質的に可能です。クライアントがHTTPSを使用しないようにだまされない限り、送信されているメッセージをだれも読み取ったり変更したりすることはできません。

  • GETとPOSTはHTTPリクエストを行う2つの方法にすぎません。他にもいくつかあります。メソッドは単なるHTTPリクエストのプロパティです。HTTPに関係なく、すべてのメッセージはリクエストとレスポンスの両方で保護されます使用されているメソッド。

20
Palec

SSLは転送中のデータを暗号化して保護します。クライアントに対して、データが傍受または変更されることなく自分のコンピューターからサーバーに送信されることを保証するだけです(暗号化されたデータは傍受される可能性がありますが、復号化なしでは意味がありません)。つまり、サーバーからデータまたは信頼出力を送信する前に、SSLが適切に機能していることを確認するのはクライアントの責任です。接続からSSLを削除する攻撃がありますが、保護されたSSL接続を介して送信されたデータを傍受または変更することはありません。

データがサーバー上にある場合、SSLはセキュリティを提供しません。保管中のデータを侵害からサーバー自体に保護する場合は、ハッシュとサーバー側の暗号化を使用する必要があります。

HTTPSは、SSL暗号化接続を介して送信されるHTTPです。 GETとPOSTおよびその他のHTTPアクションの両方をカバーします。HTTPストリーム全体が変更されずに発生し、SSLトンネルを介してクライアントブラウザーに渡されるためです。

26
AJ Henderson

SSLは、クライアントとサーバー間の接続のみを保護します。理論的にはそれはかなりうまくいきます(OK、いくつかの問題があります-しかし、他のすべての問題と比較するとこれらは軽微です)。中間CAを提供して、中間者攻撃を実行します。

そして、私が言ったように、それはクライアントとサーバーの間の接続のみを保護します。そのため、接続が暗号化されていても、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、SQLインジェクション、安全でないセッションIDなどのWebアプリケーションの問題はほとんど機能します。また、サーバーが侵害される可能性もあります。

要約すると、SSLはデータを保護するために必要なものですが、データを安全に保つために必要なことはそれだけではありません。

11
Steffen Ullrich

誰から通信を保護しようとしていますか? NSAまたはその他の州レベルのセキュリティ機関であれば、答えは「いいえ」です。彼らには、SSLに対するman-in-the-middle攻撃を正常に実装するためのリソースとテクノロジーがあります。それがNSA et al。のように認証局を危険にさらすことはできませんが、マシン自体を簡単に危険にさらして、暗号化の前と後の送信データ。ただし、サーバーをホストしているだけの場合は、エンドユーザーのマシンで侵害が発生し、問題が発生する可能性が非常に高いため、心配する必要はありません。 。それがランダムなパケットスニッファーがデータを盗んで悪用しようとする場合は、はい-そして前述のことにもかかわらず、可能な場合は常にSSLを使用する必要があります。

1
Robotman

他の回答が言及しなかった重要な詳細の1つは、SSLが要求のURLを暗号化しないことです。 GETスキームでは、データは通常URLのパラメーターとしてエンコードされます。つまり、GETを介してパスワードフィールドを含むフォームを送信しても、パスワードは暗号化されません。

0
stovetop