HTTPS URLは暗号化されていますか？
TLS/SSL（HTTPS）暗号化を使用する場合、すべてのURLは暗号化されていますか？ TLS/SSL（HTTPS）を使用している場合、すべてのURLデータを非表示にしたいので、知りたいのですが。
TLS/SSLがあなたに完全なURL暗号化を与えるならば、私はURLから機密情報を隠すことについて心配する必要はありません。
はい、SSL接続はTCPレイヤーとHTTPレイヤーの間にあります。クライアントとサーバーは最初に（SSL/TLSプロトコルを介して）安全な暗号化されたTCP接続を確立し、次にクライアントはその暗号化されたTCP接続。
誰もワイヤーキャプチャを提供していないので、ここにあります。
サーバー名（URLのドメイン部分）は、ClientHelloパケットのプレーンテキストで示されます。
以下は、ブラウザへのリクエストを示しています。https://i.stack.imgur.com/path/?some=parameters&go=here
こちらの回答をご覧ください TLSバージョンフィールドの詳細については（バージョンではなく、それぞれにバージョン番号が含まれるフィールドが3つあります！）
https://www.ietf.org/rfc/rfc3546.txt から：
3.1。サーバー名の表示
[TLS]は、クライアントが接続しているサーバーの名前をサーバーに伝えるメカニズムを提供しません。クライアントがこの情報を提供して、複数の基盤となる単一のネットワークアドレスにある「仮想」サーバー。
サーバー名を提供するために、クライアントは（拡張）クライアントhelloにタイプ "server_name"の拡張子を含めることができます
要するに：
FQDN（URLのドメイン部分）MAY送信されるin clear SNI拡張が使用されている場合は
ClientHelloパケット内リクエストURLはHTTPのもの（OSIレイヤー7）であるため、残りのURL（
/path/?some=parameters&go=here）はClientHello内に存在しません。したがって、TLSハンドシェイク（レイヤー4または5）には表示されません。これは、後でGET /path/?some=parameters&go=here HTTP/1.1HTTP要求で発生します。AFTER the secure TLSチャネルが確立されます。
エグゼクティブサマリー
ドメイン名は（SNI拡張がTLSハンドシェイクで使用される場合）クリアに送信される場合がありますが、URL（パスとパラメーター）は常に暗号化されます。
2019年3月の更新
carlin.scott これをアップしてくれてありがとう。
SNI拡張のペイロードは、 このRFC提案案 で暗号化できるようになりました。この機能はTLS 1.3にのみ存在し（オプションとして実装するのは両端までです）、TLS 1.2以下との後方互換性はありません。
CloudFlareはそれを行っており、ここで内部の詳細を読むことができます— 鶏が卵の前に来る必要がある場合、鶏をどこに置きますか？
実際には、これはFQDNをプレーンテキスト（Wiresharkキャプチャショーのように）で送信する代わりに、暗号化されることを意味します。
注：これは、逆DNSルックアップが目的の宛先ホストを明らかにする可能性があるため、セキュリティ面よりもプライバシー面に対処します。
URLを含め、リクエストとレスポンス全体が暗号化されます。
HTTPプロキシを使用するとき、それはターゲットサーバのアドレス（ドメイン）を知っていますが、このサーバの要求されたパスを知りません（すなわち要求と応答は常に暗号化されています）。
私は以前の答えに同意します：
明確にするために：
TLSでは、URLの最初の部分（ https://www.example.com/ ）は接続を確立するときにまだ表示されています。 2番目の部分（/ herearemygetparameters/1/2/3/4）はTLSで保護されています。
しかし、GETリクエストにパラメータを入れるべきではない理由がいくつかあります。
まず、他の人がすでに述べたように、 - ブラウザのアドレスバーからの漏洩 - 履歴からの漏洩
それに加えて、http refererを介したURLの漏洩があります。ユーザーはTLS上のサイトAを見て、それからサイトBへのリンクをクリックします。両方のサイトがTLS上にある場合、リクエストのリファラーパラメータまた、サイトBの管理者はサーバーBのログファイルからそれを取得できます。
Marc Novakowskiからの有益な回答への追加 - URLはサーバー上のログに保存されます（例えば、/ etc/httpd/logs/ssl_access_logに） URLに入れないでください。
はいといいえ。
サーバーアドレス部分は、接続の設定に使用されるため、暗号化されていません。
これは、暗号化されたSNIおよびDNSによって将来変更される可能性がありますが、2018年現在、両方のテクノロジは一般に使用されていません。
パス、クエリ文字列などは暗号化されています。
GETリクエストについては、ユーザーはロケーションバーからURLを切り取って貼り付けることができるので、画面を見ている人に見られるような機密情報をそこに入れることはおそらく望まないでしょう。
トラフィックを監視しているサードパーティも、トラフィックを調べて、そのサイトを訪問したときに他のユーザーが持っているトラフィックと比較することで、訪問したページを特定できる可能性があります。たとえば、1つのサイトに2ページしかなく、一方が他方よりはるかに大きい場合、データ転送のサイズを比較すると、どのページにアクセスしたかがわかります。これがサードパーティから隠される可能性がある方法がありますが、それらは通常のサーバーまたはブラウザの動作ではありません。例えばSciRateからのこの論文、 https://scirate.com/arxiv/1403.0297 を参照してください。
このペーパーでは、訪れたページ（つまりURL）を非常に効果的に判断できることを示していますが、一般的に他の答えは正しいです。
あなたはいつも完全なURLのプライバシーを常に頼りにすることはできません。たとえば、企業ネットワークの場合と同様に、会社のPCなどの付属デバイスには追加の「信頼できる」ルート証明書が設定されているため、ブラウザはhttpsトラフィックのプロキシ（中間者）検査を静かに信頼できます。 。これは、完全なURLが検査のために公開されていることを意味します。これは通常ログに保存されます。
さらに、あなたのパスワードも公開され、おそらくログに記録されます。そしてこれが ワンタイムパスワード を使うもう一つの理由です。
最後に、リクエストとレスポンスのコンテンツも暗号化されていなければ公開されます。
検査設定の一例は ここでのチェックポイント で記述されています。付属のPCを使った古いスタイルの「インターネットカフェ」もこの方法でセットアップできます。
重複した質問に対する私の回答へのリンク 。ブラウザの履歴で利用可能なURLだけでなく、サーバー側でもログに記録されるだけでなく、サードパーティのコンテンツを使用する場合は自分の管理外のソースにURLを公開するHTTP Refererヘッダーとしても送信されます。
現在は2019年で、TLS v1.3がリリースされました。クラウドフレアによると、SNIはTLS v1.3のおかげで暗号化することができます。だから、私は自分自身素晴らしいと言いました！それがcloudflare.comのTCPパケット内でどのように見えるかを見てみましょう。それで、私はcloudflareサーバの応答から "client hello"ハンドシェイクパケットを捕らえました。私はまだプレーンテキストでサーバー名を読むことができます。
それで、仲介者がターゲットサーバー名を見ることができるのでこれがまだ匿名接続ではないのであなたが読むことができるものに注意してください。
そのため、SNIの暗号化ではTLSv1.3と連携するために追加の実装が必要になるようです。
次の記事では、TLSv1.3の一部としてCloudflareによって提供されるSNIの暗号化について説明します。しかし、cloudlfare.comからのすべてのHTTP URLはTLS v1.3の下のTCPパケットの中で平文で読むことができます。
ここにはすでにいくつかの良い答えがありますが、それらのほとんどはブラウザナビゲーションに焦点を当てています。私は2018年にこれを書いていますが、おそらく誰かがモバイルアプリのセキュリティについて知りたいのです。
モバイルアプリの場合 、アプリケーションの両端（サーバーとアプリ）を制御している場合は、HTTPSを使用している限り 安全です 。 iOSまたはAndroidが証明書を検証し、起こり得るMiM攻撃を軽減します（これが唯一の弱点になります）。あなたはそれが暗号化されることをHTTPS接続を通して機密データを送ることができます 輸送中 。あなたのアプリとサーバーだけがhttpsを通して送られたどんなパラメータでも知っているでしょう。
Httpsにラップされる前にデータを見ることができる悪意のあるソフトウェアにクライアントまたはサーバーが感染している場合、これが唯一の「多分」となります。しかし、誰かがこの種のソフトウェアに感染している場合、あなたがそれを輸送するために何を使用しても、彼らはデータにアクセスすることができます。
さらに、ReSTful APIを構築している場合は、クライアントがブラウザではないことやリンクをクリックする人がいないことがあるため、ブラウザの漏洩やhttp refererの問題はほとんど軽減されます。
このような場合は、ベアラトークンを取得するためにoAuth2ログインをお勧めします。その場合、唯一の機微なデータは初期の信用証明書であるでしょう…とにかくポストリクエストにあるべきです