web-dev-qa-db-ja.com

HTTPSの場合、URLとリクエストヘッダーはリクエスト本文と同様に保護されますか?

確認したいのは、SSL接続(httpポスト)を行うときに次のように言うことです。

https://www.example.com/some/path?customer_key=123123123

Customer_keyについて誰にも知られたくない場合は、https接続を正しく設定しても、このアプローチは機能しませんか?

保護したいすべてのデータは、リクエストの本文にある必要がありますか?

31
codecompleting

引用 HTTPS RFC

TLSハンドシェイクが終了したとき。次に、クライアントは最初のHTTP要求を開始します。すべてのHTTPデータはTLS「アプリケーションデータ」として送信する必要があります。

基本的に、安全なSSL/TLSチャネルが最初に確立されます。その場合にのみ、HTTPプロトコルが使用されます。これにより、HTTPヘッダー(URLとCookieを含む)を含め、SSLを使用してすべてのHTTPトラフィックが保護されます。

ハンドシェイクに表示される可能性があるのは、ホスト名自体です。これは、ハンドシェイクで明確に表示されるサーバー証明書に含まれているためです(宛先IPアドレスを確認することでホスト名を推測するのは簡単です)。

サーバー名表示を使用する場合、要求されたホスト名はClientHelloメッセージのserver_name拡張にも表示される必要があります。そうしないと、証明書が複数のホスト名(たとえば、複数のサブジェクトの代替名やワイルドカード)に対して有効である場合、(盗聴者にとって)証明書からホスト名を推測するのに少しあいまいさが生じる可能性があります。この場合、クライアントからのDNSリクエストを盗聴することで、攻撃者に手掛かりを与える可能性があります。

他の人の回答やコメントを読んだり、Referer(仕様でrを失った)やログに関する問題について言及したりしました。

残りの潜在的な弱点の1つはhowで、そのリンクをユーザーに提供します。プレーンHTTP経由で提供されるWebページに埋め込まれている場合、そのページを読むことができる人なら誰でも見ることができます。そのようなページもHTTPS経由で提供する必要があります。代わりに電子メールでそのリンクを送信する場合、メールサーバーはめったに暗号化せずに電子メールアカウントにアクセスするためにユーザーとユーザーの間の接続を暗号化することはほとんどないので、私はすべての賭けはオフだと思います。

編集:

さらに、クライアント証明書認証を使用している場合、クライアント証明書は、最初のハンドシェイク中にネゴシエートされると表示されます。これにより、Webサイトにアクセスしているユーザーの名前が漏洩する可能性があります(多くの場合、サブジェクトDNにはユーザー名が含まれています)。クライアント証明書は、再ネゴシエートされたハンドシェイク中に送信された場合は表示されません。

36
Bruno

スヌーパーにはwww.example.comのみが表示されます。リクエストのパスセクションはSSL/TLSで保護されています。

もちろん、HTTPSでオリジナルのハイパーリンクを送信する必要もあります。

7
artbristol

安全な接続を確立した後、要求データが送信されるので、上記のURLで心配する必要はありませんが、データは暗号化されず、サーバーとクライアント間のチャネルのみが暗号化されます。このチャネルをクラックできれば、データを明確に見ることができます。

SSLは、データの上にあるラッパー暗号化チャネルです。データがプレーンな場合、SSLを解読できる人なら誰でもあなたのデータをはっきりと見ることができます。

3
kosa

NOに対する私の答えを改訂します。どうやら、SSL接続が確立される前に、ホスト名のみがクリアテキストで送信されます。

http://answers.google.com/answers/threadview/id/758002.html

1
dbrin

場合によります..

パケットスニファを使用する場合、ネットワーク経由で送信されたデータを見ることができません。このアプローチの主な問題は、リクエストのURLがサーバーのログにプレーンテキストで保存されることが多く、ブラウザーの履歴がURLを保持し、URLがリファラーヘッダーで渡され、サードパーティのサービス(Googleアナリティクス)によって保持される可能性があることです。

0
Leo