web-dev-qa-db-ja.com

SSL / TLS（https）はアクセスされているURLを隠しますか

これをブラウザに入力するとします

https://www.mysite.com/getsecret?username=alice&password=mysecret

攻撃者は私からISPへのすべてのトラフィックを監視しています。

HTTPSで保護されている情報は何ですか？ URLは明らかにされていますか？ getリクエストのパラメーターは明らかにされていますか？

また、HTTPSはURLの整合性を提供しますか？

さまざまなHTTPSの記事とTLS仕様を調べてみましたが、これを理解することができませんでした。

[編集：]サーバーのドメイン名のみが公開されていても問題ありません。ただし、?username=alice&password=mysecret明らかにする必要があります。

tlsconfidentialityintegrity
71
Jus12

[〜＃〜] https [〜＃〜] プロトコルは、HTTPを SSLまたはTLS 接続（TCP経由）で使用するのと同じです。

したがって、最初に TCP接続 （ポート443で）がサーバーに対して開かれます。これは通常、サーバーのホスト名（つまりwww.mysite.com（あなたのケースでは）攻撃者に。 IPアドレスは直接監視されます。

  1. 通常、以前に暗号化されていないDNSクエリを実行した
  2. 多くのHTTPSサーバーはIPアドレスごとに1つのドメインのみを提供し、
  3. サーバーの証明書はプレーンに送信され、サーバー名（複数のサーバー間など）が含まれています。
  4. 新しいTLSバージョンでは、サーバー名の表示があり、クライアントがサーバーに希望のホスト名を示すため、サーバーが複数の証明書を持っている場合に、適切な証明書を提示できます。 （これは、2から離れるために行われます。）

次に、TLSハンドシェイクが行われます。これには、暗号スイートのネゴシエーションとその後の鍵交換が含まれます。ブラウザとサーバーの少なくとも1つがNONE暗号を承認済みスイートに含めなかったとすると、鍵交換に続くすべてが暗号化されます。

そして、中間者攻撃（つまり、接続を傍受し、ブラウザが受け入れる偽造サーバー証明書を提示する攻撃者）が成功しないと仮定すると、鍵交換は安全であり、盗聴者は何も復号化できません。ユーザーとサーバーの間で送信されます。また、これに気付かれずに攻撃者がコンテンツの一部を変更することはできません。これには、URLとHTTPリクエストの他の部分、およびサーバーからの応答が含まれます。

もちろん、D.W。言及、両方の長さ（URLよりも多くの可変データを含まない、おそらくいくつかのCookie）と応答は、暗号化されたデータストリームから見ることができます。これは、特にサーバー上に少数の異なるリソースしかない場合は、秘密を破壊する可能性があります。また、フォローアップリソースのリクエスト。

ただし、URL（またはリクエストのその他の部分）に含まれるパスワードは引き続き安全である必要があります-最大でもその長さはわかっています。

59
Paŭlo Ebermann

@PaŭloEbermannと@Jeff Ferlandが言ったように、GETリクエストはSSLで暗号化されているので安全です。 ただし、多くのWebサーバーがGETリクエストとパラメーターを記録し、GETを介して送信する資格情報やその他の機密情報がどこかのログに書き込まれる可能性があることを忘れないでください。そのため、機密データを送信する場合は、POST（SSLでも暗号化されます）を使用する必要があります。

これは「暗号化はすべての問題を解決する魔法のセキュリティではない」というカテゴリに分類されます。

26
gowenfawr

URLが保護されていない、つまり、パッシブ盗聴者がアクセスしているURLを知る可能性があると想定する必要があります。

これは他の何人かの人々が主張していることと矛盾しているので、私はもっとよく説明したいと思います。

ドメイン名の後のすべてが暗号化されて送信されることは事実です。たとえば、URLがhttps://www.example.com/foo/bar.html、次にwww.example.comは攻撃者に表示され、HTTPリクエスト（GET /foo/bar.html HTTP/1.0）は暗号化されています。これにより、盗聴者がURLのパス部分を直接見ることができなくなります。 ただし、URLのパス部分の長さが盗聴者に見える可能性があります。さらに、他の情報（アクセスしたページの長さなど）も盗聴者に表示される可能性があります。これは、攻撃者のドアの足です。 攻撃者がhttpsトラフィックを盗聴できる場合、ドアのこの足を使用して、訪問しているURLを知るいくつかの調査が行われています 。

これらの攻撃が成功する保証はありませんが、最悪の場合、盗聴者がアクセスしているURLを知ることができると想定することが賢明であることをお勧めします。したがって、SSL/TLSがどのページにアクセスしているかを盗聴者から隠しているとしない必要があります。

はい、httpsはアクセスしたURLの整合性を提供します。

追伸その他の注意点：実際には、Webサイトで [〜＃〜] hsts [〜＃〜 ] 。これらの攻撃は、URLの機密性と整合性の両方に違反する可能性があります。したがって、ユーザーが安全でないネットワーク（オープンWifiなど）でHSTSを使用していないWebサイトにアクセスしている場合、攻撃者がユーザーがどのページにアクセスしているかを知ることができる可能性があることに注意する必要があります。 sslstrip脅威に対する1つの部分的な緩和策は、ユーザーが HTTP Everywhere を使用することと、サイトがHSTSを採用することです。

25
D.W.

セッションが開始する前に、次のものがリークします。

  • サーバーのIPアドレス
  • サーバーの証明書
    • これには、証明書で公開されたドメイン名が含まれますが、使用したドメイン名と一致するとは限りません。
  • DNSクエリ

SSL接続の作成に関連しないデータやリクエストはありません（GET ...）は、SSLセッションが開始する前にサーバーに送信されます。 URLはページ要求の一部として送信され、セッションの一部であるトラフィックと同じように保護されます。

12
Jeff Ferland

はいといいえ。

URLは適切に暗号化されているため、クエリパラメータを直接公開しないでください。

ただし、トラフィック分析はURLの長さを頻繁に取得する可能性があり、特にページ上のリンクがクリックされたと想定している場合は、サーバーとURLの長さを知るだけで、アクセスされているページを盗聴できることがよくあります。 「トラフィック分析sslブラウジング」、またはトピックに興味がある場合は類似したもののグーグル。

ユースケースでは、これはわずかに重要です。トラフィック分析を巧みに使用すると、フェッチされた他のURLにもユーザー名が含まれているかどうかによって、ユーザー名の長さやパスワードの長さ、あるいはその両方が明らかになる場合があります。ユーザー名/パスワードを一定の長さに埋め込むと、これらの攻撃を回避できますが、面倒な価値はありません。

11
Nakedible

TLSスタックはサーバー名表示（SNI、 http://en.wikipedia.org/wiki/Server_Name_Indication ; http://www.ietf.org/rfc/rfc3546）を送信し始めています.txt ）。これは平文で送信されます。つまり、盗聴者は、アドレスバーに入力したサーバー名を見ることができます。

9
Steve Dispensa