web-dev-qa-db-ja.com

公共のホットスポットでHTTPS Webサイトにアクセスすることは安全ですか？

サーバーと私の間の通信は暗号化されている（サーバー認証も提供する）ため、HTTPS SSL/TLS接続は暗号化され、安全であると言われることがよくあります。理論的には力。

私がパブリックwifiを使用していて、すべてのパケットを盗聴する同じwifiに悪意のあるユーザーがいるとします。次に、このwifiを使用してGmailアカウントにアクセスしようとしていると仮定します。私のブラウザはサーバーとSSL/TLSハンドシェイクを行い、暗号化と復号化に使用するキーを取得します。

その悪意のあるユーザーがすべての着信パケットと発信パケットを盗聴した場合。彼は同じ鍵を計算して私の暗号化されたトラフィックも読み取ることができますか、それとも私の名前でサーバーに暗号化されたメッセージを送信することさえできますか？

tlsweb-browserwifi
148
Calmarius

HTTPSは公共のホットスポット上で安全です。 HTTPSで使用されるセキュリティレイヤーである [〜＃〜] tls [〜＃〜] のセットアップ中に、公開鍵と暗号化されたメッセージのみが送信されます（これらもルート証明書によって署名されます）。クライアントは公開鍵を使用してマスターシークレットを暗号化し、サーバーはそれを秘密鍵で復号化します。すべてのデータは、マスターシークレットと両側で生成された疑似乱数を使用する関数で暗号化されます。

したがって、

  • マスターシークレットと疑似乱数によって署名されているため、データは安全です
  • マスターシークレットと疑似乱数は、TLSハンドシェイクが発生したときに公開鍵と秘密鍵の暗号化を使用するため、安全です。
  • 公開鍵と秘密鍵の暗号化は次の理由で安全です：
    • 秘密鍵は秘密にされます
    • 公開鍵と秘密鍵の暗号化は、秘密鍵がないと役に立たないように設計されています
    • 公開鍵はルート証明書によって署名されているため、正当であることがわかっています。
    • コンピュータに付属
    • またはあなたによって特別に承認されました（ブラウザの警告に注意してください！）

したがって、次の条件を満たす限り、HTTPS接続とデータは安全です。

  1. コンピュータに付属している証明書を信頼している
  2. 信頼できる証明書のみを承認するように注意してください。
109
waiwai933

短い答え：場合によります。

SSL/TLS自体は、「通常の」インターネットよりも、公共のwifi接続を介して脆弱ではありません。オープンチャネルで使用するように設計されています。

ただし、考慮すべき他のいくつかの側面があります。

  • 多くの場合、ユーザーはHTTPSサイトを直接参照せず、HTTPサイトから始めて、そこからリダイレクトします。たとえば、http://example.org/を参照し、Emailリンクをクリックすると、https://mail.example.org/にリダイレクトされます。元のHTTPページは暗号化されていないため、その悪意のあるユーザーがトラフィックを変更し、EmailリンクがHTTPSにリダイレクトされないようにする可能性があります。たとえば、example.orgのホームページでEmailリンクをクリックした場合、http://mail.exxxample.org/に移動したことがわかりますか？ （例として）。 あなたはそうかもしれませんが、他の誰かはそうではないかもしれません。
  • ユーザーが接続を乗っ取るが、example.orgの代わりに独自の偽のSSL証明書を提供する場合-ブラウザーはエラーを表示し、証明書が無効であることを示します。ただし、ほとんどのユーザーはこれをクリックするだけで、攻撃者はSSLを介して安全なサイトにMITMできます。
  • 考慮すべきもう1つの側面は、パブリックホットスポットが安全に構成されていると想定しないことです。 この質問が示すように のように、pwnedルーターはすべて一般的すぎて、SSLに関係なく、はるかに大きな損害を引き起こす可能性があります。
48
AviD

ブラウザからのすべてのリクエストとサーバーによって送信されるページが暗号化されるため、完全にHTTPSを介したセッションはかなり安全です。

ただし、HTTPS経由でアクセスした場合、多くのサイトはHTTPS経由でのみ認証ステップを実行し、残りのセッションではHTTPに戻ります。したがって、パスワード自体は安全ですが、サーバーがそのセッションのためにユーザーを識別するために使用するセッションIDは、ブラウザーによって平文で送信されます。これにより、Webサーバーの負荷は軽減されますが（暗号化/復号化はCPUを集中的に使用するため）、サイトのセキュリティは大幅に低下します。 Gmailはセッション全体でHTTPSを使用するため安全ですが、Facebookや他の多くのサイトでは使用していません。

これは、攻撃者が暗号化されていないワイヤレスネットワークを共有しているときに、 Firesheep などのツールがユーザーのアカウントを乗っ取る方法です。

VPNを使用してすべてのセッションデータを暗号化するか、WPA-PSK（WEPはすべてのユーザーに同じキーを使用するため、この攻撃からの保護を提供します）。

22
Alex Howell

答えはあちこちにあるようです（そう、そう、そうかもしれませんが、そうであるはずです）。最初に@ waiwai933の答えを繰り返します。それは安全です。

具体的には、「悪意のあるユーザーがすべての受信パケットと送信パケットを盗聴した場合、同じキーを計算して暗号化されたトラフィックも読み取ったり、暗号化されたメッセージを自分の名前でサーバーに送信したりできますか？」答えはノー、ノーです。脚注付き。

彼が同じ鍵を計算できない理由は逆説的であるように思われ、実際、それがDiffieとHellmanによって最初に公開されたとき、暗号化における大きな進歩でした。 TLSは、Diffie-Hellmanのようなキー交換プロトコルを使用しますが、中間者攻撃から保護するためにより高度です。このプロトコルを使用すると、情報を交換したことがない2人が、すべてのメッセージを見ても誰も計算できない秘密鍵を計算できます。

共有秘密鍵を取得したら、それを使用してトラフィックを暗号化できます。悪意のあるユーザーはキーを知らないので、あなたから来たように見えるトラフィックを暗号化することはできません。

今それらの脚注。

  • SSL/TLSプロトコルが正しいと想定しています。最も複雑な暗号プロトコルでは、バグが発見され、時々修正されます。 SSL/TLSには最近のバグがありました（安全でない理由としていくつかの回答で言及されています）が、一時的に回避され、現在は fixed（RFC 5746） であり、修正は展開のさまざまな段階。 （このシナリオでは、このバグにより、悪意のあるユーザーがあなたの名前でパケットを送信することはできましたが、トラフィックを読み取ることはできませんでした。プロトコルの未公開エラーが原因で、攻撃者がTLS/SSLを破る方法を知っている可能性は常にあります。
  • 明らかなポイントですが、繰り返す価値があります。悪意のあるユーザーがあなたのリクエストを見て、自分の証明書を使用して自分の応答を送信する可能性があります。証明書を確認してください。
  • おそらくもう1つの明白な点：現在のページがHTTPSである場合にのみ、SSL/TLSが将来のページで使用されることを確認できます。たとえば、ログインを要求するHTTPページを使用していて、過去の経験から、ログインボタンをクリックするとHTTPS接続にリダイレクトされることがわかっている場合、アクティブな悪意のあるユーザーによってこの機能が取り除かれる可能性があります。ネットワーク上。そのため、すでにHTTPSであるページにのみログインしてください（ログインページが変更されたかどうかを検出する方法を知っている場合を除きます）。
13
PulpSpy

安全でないネットワークを介してサイトを安全に閲覧することを懸念している場合、セキュリティを確保するために実行できる最善の手順は次のとおりです。

  • サイトがHTTPではなくHTTPSを使用していることを確認してください。

  • サイトに有効な証明書があることを確認してください。警告をクリックしないでください。無効な証明書を受け入れないでください。

  • HTTPS Everywhere または Force-TLS を使用して、そのサイトに関連するすべてにHTTPS（つまり、SSL暗号化）接続を使用していることを確認します。

2
D.W.

HTTPSは、パケットスニッフィングからの復号化にかなり耐性があります。ただし、サーバー認証側はCA証明書を配布するやや弱い方法に依存しており、CAはIDの検証に関してあまり機能しません。数年前、マイクロソフトの証明書は 詐称者に発行されました でした。 Bruce Schneierの 主題に関する記事 を参照してください。実際には、一般の公開Webサイトについては、これ以上のことはありません。

2
RedGrittyBrick

実際には、SSLとTLSの両方に問題がありますが、これらはMan In the Middleタイプの攻撃に関連しています。 TLS MITM再ネゴシエーションの問題の例については、 こちら を参照してください

もちろん、この攻撃では、攻撃者が通信経路の真ん中にいる必要があり、脅威を少し制限します:-)

2
Rory Alsop

完全に、実際に。暗号化はルートのsslの人々（Verisign、Thawteなど）から始まるため、安全でない回線に適しています。 AFAIK TLSは、中間者攻撃では問題がありません。その問題があるのは、弱い/古いハンドシェイクだけです。

1
tobylane

ほとんどは、ユーザーの側面と、ホットスポットでそのPCをどのように使用するかを忘れています。ほとんどの人が他のサイトで同様のパスワードを使用している、ブログを書いているなど...それらはあなたが接続しているかもしれないHTTPS/SSL gmailほど安全ではないかもしれません。セキュリティ上の問題から、ほとんどの人は他のサイトにアクセスして、一部のアカウントを取得するのに十分な情報を含むパケットスニッフィングプログラムを公開します。暗号化されていないワイヤレス接続を使用している場合は、ベストです。できれば、接続できるVPNがあれば、セキュリティがさらに強化されます。

1
IrqJD

安全な接続（ssl）に関する限り、接続は非常に安全です。提供されていますが、意識して使用されている場合：

  • HTTPSからHTTPへのリダイレクトはありません
  • 一部のサイトでは、HTTPSページ上でHTTPコマンドも使用しています。これを介して送信される機密情報はありません。
  • 弱い設定のhttpsサーバーと古いブラウザは、安全なソケットを介しても利用できます
0
8zero2.ops