GETデータもHTTPSで暗号化されますか？

回答:

145

リクエスト全体が暗号化されます。URLやコマンド（GET）も含まれます。プロキシサーバーなどの仲介者が収集できる唯一のことは、宛先アドレスとポートです。

ただし、TLSハンドシェイクのClient Helloパケットは、SNI拡張を介して完全修飾ドメイン名をプレーンテキストでアドバタイズできることに注意してください（@hafichukに感謝）。これは、最近のすべてのメインストリームブラウザーで使用されますが、一部は新しいOSでのみ使用されます。

編集：（これで「良い答え」のバッジがついただけなので、質問全体に答える必要があると思います…）

応答全体も暗号化されます。プロキシはその一部を傍受できません。

検索やその他のコンテンツは、すべてが公開されているわけではないため、Googleがhttps経由で提供しています。また、一部の公開コンテンツをMITMから非表示にすることもできます。いずれにしても、Google に自分で答えさせるのが最善です。

— マルセロ・カントス
ソース
2
URLが暗号化されているという申し立てに少し不満があります。ホスト名はURLの一部と見なされていませんか？もしそうなら、ステートメントは間違っています。物理メールの送信中に宛先アドレスを非表示にできないのと同じように、ISP /プロキシサーバーからホスト名/ IPアドレスを非表示にする方法はありません。
— Abhishek Anand 2014年
1
@Abhishek：ホスト名がTCP / IPヘッダーにありません。回答ではIPアドレスについて説明します。
— Marcelo Cantos 2014年
ドメインは暗号化されていません。これは、名前ベースの仮想ホスト（対IPベース）をサポートするためのものです。@MarceloCantosは完全に正しく、残りのURL（つまりGETコマンド）は暗号化されています。これはRFC 4366で
— hafichuk '11 / 07/17
@hafichuk：ありがとうございます。TLSがfqdnをアドバタイズできることを知りませんでした。最後にhttpsマルチサーバーをセットアップしようとしたとき（数年前、認めます）、単一のIPでは不可能に思えました。
— Marcelo Cantos 14
ドメイン名を含むTLSへの本当に重要な追加：ドメイン名を含むプレーンテキストのDNSリクエストを忘れないでください。あなたの暗号化されたHTTPSトラフィックを見ることができる誰かがあなたのDNSリクエストも見ることができる可能性があります。
— Tim G
63

URL自体は暗号化されているので、クエリ文字列のパラメーターはネットワーク上を単純に移動しません。

ただし、GETデータを含むURLは多くの場合Webサーバーによってログに記録されますが、POSTデータはほとんどログに記録されないことに注意してください。したがって、のようなことを計画している場合/login/?username=john&password=doeは、しないでください。代わりにPOSTを使用してください。

— トーマス
ソース
2
+1ありがとうございます。これは自分の物理サーバー上にあるので、ログについて心配する必要はありませんが、共有ホスティング環境でこれを検討している人にとっては、これは良い考慮事項です。私はこの方法でクレジットカード番号を転送し、間違いなくそれらをログに記録しないので、考慮することも重要です:)
— orokusaki
3
それがあなた自身の箱であることは本当に重要ではありません。また、それを所有している他の誰（つまり、悪意のあるハッカー）にも、それらのパスワードがプレーンテキストで表示されることを望まないでしょう。または、それらのCC番号（それらを他の場所にも保存しないと想定）。
— Thomas
1
これらは、URLクエリ文字列ではなく、POST本文に配置する必要があります。
— トーマス
1
wbeserverのログへのアクセスに対する制限は、Webサイトのデータ（DB、ファイルなど）へのアクセスよりも少ないと思いますか？IMHOデータがWebサーバーに安全にアクセスする限り、すべて順調です。Webサーバーにアクセスできる唯一の人々は信頼できると見なされるべきです。なぜなら、そうでなければ、何らかの方法でデータを読み取るのを防ぐことができないからです。
— Serge Profafilecebook 2015
1
パスワードがGETを介して送信され、アクセスログに記録される場合、ハッシュされません。それが最大の問題だと思います。Webサーバーのアクセスログでパスワードを検索するだけでよい場合、データベースでハッシュされたパスワードを使用することは重要ではありません。それらはデータベースでハッシュされるべきです、そうでなければ、それを修正してください。
— SteenSchütt、2015年
21

HTTPS HTTPデータが転送される前に、基礎となるSSL接続を確立します。これにより、すべてのURLデータ（接続の確立に使用されるホスト名を除く）がこの暗号化された接続内でのみ伝送され、HTTPSデータと同じように中間者攻撃から保護されます。

上記は、ここにあるGoogle Answersからの非常に包括的な回答の一部です。

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

— DVK
ソース
6

すべてが暗号化されていますが、クエリはサーバーのログに残り、さまざまなログアナライザーなどからアクセスできることを覚えておく必要があります（通常、POSTリクエストの場合はそうではありません）。

— ユージーン・マイエフスキーコールバック
ソース
1
どのサーバー？誰がアクセスできますか？
— Jader Dias、
2
@Jader、少なくともそのサーバーの管理者とハッカーに。POSTリクエストの場合、情報はログにとどまらないため、明示的にログに記録されない限り、ログに問題はありません。GETクエリはログに残り、ログで何かが発生した場合（または管理者がこれらのログを不正なアクティビティに使用することを決定した場合）、問題が発生します。
— Eugene Mayevski 'Callback
4

接続は、要求が送信される前に暗号化されます。つまり、クエリ文字列を含め、リクエストも暗号化されます。

— チャオ
ソース
4

はい、安全です。SSLはすべてを暗号化します。

POSTリクエストからの抜粋：

POST /foo HTTP/1.1
... some other headers

GETリクエストからの抜粋：

GET /foo?a=b HTTP/1.1
... some other headers

どちらの場合も、ソケットで送信されるものはすべて暗号化されます。クライアントが GETリクエスト中にブラウザでパラメータを見るという事実は、真ん中の男が同じことを見るとは限らない。

— ダリン・ディミトロフ
ソース
4

HTTPS経由でウェブサイトに接続し、一連のGETパラメータを渡しました。次に、wiresharkを使用してネットワークを盗聴しました。HTTPを使用すると、URLは暗号化されずに送信されます。つまり、URL内のすべてのGETパラメーターを簡単に確認できます。HTTPSを使用すると、すべてが暗号化され、どのパケットがGETコマンドであるのか、さらにはその内容はわかりません！

— ジェフ・ラム
ソース
3

SSLはヘッダー解析の前に行われます。つまり、

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

リクエストは次のようになります（正確な構文を覚えることはできませんが、これで十分です）：

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

これは、同じIP上の複数のホストに異なるSSL証明書を使用することが問題になる理由でもあります。要求されたホスト名は解読されるまでわかりません。

— モルフィルダー
ソース
1
HTTP/1.1最初の行の末尾に来ます。
— Marcelo Cantos
@Marcelos Cantos：おかげで、手動でHTTPリクエストを記述しなければならなくなって久しぶりです。
— Morfildur 2010年
0

HTTPSを使用する場合、GETリクエストは暗号化されます。実際、これがセキュリティで保護されたWebサイトに一意のIPアドレスが必要な理由です。解読されるまで、リクエストから目的のホスト名（または仮想ディレクトリ）を取得する方法はありません。

— マイケル・バー
ソース
JFYI：クライアントがホスト名を指定できるようにするTLS拡張があり、サーバーは対応する証明書を選択できます。
— Eugene Mayevski 'Callback
@Eugene：ありがとう-私はTLS拡張を知っていますが、最も緩い意味でのみです-詳細や、実際に使用されている（または使用されていない）可能性については何も知りません。
— Michael Burr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.