TLS / SSL（HTTPS）暗号化を使用する場合、すべてのURLが暗号化されますか？TLS / SSL（HTTPS）を使用するときにすべてのURLデータを非表示にしたいので、知りたいのですが。

TLS / SSLが完全なURL暗号化を提供する場合、私はURLから機密情報を隠すことについて心配する必要はありません。

はい、SSL接続はTCP層とHTTP層の間にあります。クライアントとサーバーは、最初に（SSL / TLSプロトコルを介して）安全な暗号化されたTCP接続を確立し、次にクライアントはその暗号化されたTCP接続を介してHTTP要求（GET、POST、DELETE ...）を送信します。

誰もワイヤキャプチャを提供しなかったので、こちらをご覧ください。
サーバー名（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」の拡張を含めることができます（MAY）。

要するに：

• FQDN（URLのドメイン部分は）MAY送信することが明らかに内部のClientHelloSNI拡張機能が使用されている場合、パケット

• リクエストURLはHTTPのもの（OSIレイヤー7）であるため、残りのURL（/path/?some=parameters&go=here）は内部に存在しませんClientHello。したがって、TLSハンドシェイク（レイヤー4または5）には表示されません。それは中に後で来るGET /path/?some=parameters&go=here HTTP/1.1、HTTPリクエストAFTER 安全な TLSチャネルが確立されています。

エグゼクティブサマリー

ドメイン名は平文で送信できますが（TLSハンドシェイクでSNI拡張が使用されている場合）、URL（パスとパラメーター）は常に暗号化されます。

2019年3月更新

これを取り上げてくれて、carlin.scottに感謝します。

SNI拡張のペイロードは、このドラフトRFC提案によって暗号化できるようになりました。この機能はTLS 1.3にのみ存在し（オプションとして、実装するかどうかは両端にあります）、TLS 1.2以下との下位互換性はありません。

CloudFlareがそれを行っており、内部についての詳細はこちらで読むことができます— 鶏が卵の前に来る必要がある場合、鶏をどこに置きますか？

実際には、これはFQDNをプレーンテキストで送信する（Wiresharkキャプチャショーのように）代わりに、暗号化されることを意味します。

注：これは、DNSの逆引きにより、意図した宛先ホストが明らかになる可能性があるため、セキュリティよりもプライバシーの側面に対処します。

他の 答えはすでに指摘されている、https「のURLは、」確かに、暗号化されています。ただし、ドメイン名を解決する際のDNS要求/応答はおそらくそうではありません。もちろん、ブラウザーを使用している場合は、URLも記録される可能性があります。

リクエストとレスポンス全体が、URLを含めて暗号化されます。

HTTPプロキシを使用すると、ターゲットサーバーのアドレス（ドメイン）は認識されますが、このサーバーで要求されたパスは認識されません（つまり、要求と応答は常に暗号化されます）。

私は以前の答えに同意します：

明確にするために：

TLSを使用すると、URLの最初の部分（https://www.example.com/）は、接続を確立するときに引き続き表示されます。2番目の部分（/ herearemygetparameters / 1/2/3/4）はTLSで保護されています。

ただし、GETリクエストにパラメータを含めない理由はいくつかあります。

まず、すでに他の人が述べたように：-ブラウザのアドレスバーからの漏洩-履歴からの漏洩

それに加えて、httpリファラーを介したURLの漏洩があります。TLSでサイトAが表示され、サイトBへのリンクをクリックします。両方のサイトがTLSにある場合、サイトBへのリクエストには、サイトAからの完全なURLが含まれます。リクエストのリファラーパラメータ。また、サイトBの管理者は、サーバーBのログファイルからそれを取得できます。

Marc Novakowskiからの役立つ回答への追加-URLはサーバーのログ（たとえば、/ etc / httpd / logs / ssl_access_log）に保存されているため、サーバーが長期間にわたって情報を保持したくない場合用語は、URLに含めないでください。

はいといいえ。

サーバーアドレス部分は、接続のセットアップに使用されるため、暗号化されません。

これは、暗号化されたSNIとDNSで将来変更される可能性がありますが、2018年の時点では、両方のテクノロジーは一般的に使用されていません。

パス、クエリ文字列などは暗号化されます。

GETリクエストについては、ユーザーは引き続きロケーションバーからURLを切り取って貼り付けることができます。また、画面を見ている人に見られる可能性のある機密情報をそこに配置したくない場合もあります。

トラフィックを監視しているサードパーティも、トラフィックを調べて、他のユーザーがサイトにアクセスしたときのトラフィックと比較することで、アクセスしたページを特定できる場合があります。たとえば、サイトに2ページしかなく、一方が他方よりもはるかに大きい場合、データ転送のサイズを比較すると、どのページにアクセスしたかがわかります。これをサードパーティから隠す方法はいくつかありますが、それらは通常のサーバーまたはブラウザの動作ではありません。たとえば、SciRateのこのペーパー（https://scirate.com/arxiv/1403.0297）を参照してください。

一般に、他の回答は正しいですが、実際にはこのペーパーでは、アクセスしたページ（URL）を非常に効果的に特定できることを示しています。

完全なURLのプライバシーを常に信頼できるわけではありません。たとえば、エンタープライズネットワークの場合と同様に、会社のPCなどの提供されたデバイスは、追加の「信頼できる」ルート証明書で構成されているため、ブラウザーはhttpsトラフィックのプロキシ（中間者）検査を静かに信頼できます。 。つまり、完全なURLが検査のために公開されます。これは通常、ログに保存されます。

さらに、パスワードも公開され、おそらくログに記録されます。これがワンタイムパスワードを使用するもう1つの理由ですしたり、パスワードを頻繁に変更したりです。

最後に、要求と応答のコンテンツも、暗号化されていない場合は公開されます。

検査のセットアップの一例は、チェックポイントがここで説明しています。付属のパソコンを使った昔ながらの「インターネットカフェ」もこの方法で設置できます。

重複する質問に対する私の回答へのリンク。ブラウザの履歴で利用できるURLだけでなく、サーバー側のログだけでなく、サードパーティのコンテンツを使用する場合に、コントロールの外部のソースにURLを公開するHTTPリファラーヘッダーとしても送信されます。

現在は2019年で、TLS v1.3がリリースされました。Cloudflareによると、TLS v1.3のおかげでSNIを暗号化できます。だから、私は自分に素晴らしいと言いました！cloudflare.comのTCPパケット内でどのように見えるかを見てみましょう。そこで、ブラウザーとしてGoogle Chromeを使用し、パケットスニファーとしてWiresharkを使用して、cloudflareサーバーの応答から「クライアントハロー」ハンドシェイクパケットをキャッチしました。それでも、Client helloパケット内のサーバー名をプレーンテキストで読み取ることができます。

これはまだ匿名接続ではないので、何を読むことができるかに注意してください。クライアントとサーバー間のミドルウェアは、クライアントから要求されたすべてのドメインをログに記録できます。

したがって、SNIの暗号化にはTLSv1.3と連携するために追加の実装が必要であるように見えます

次の記事では、TLSv1.3の一部としてCloudflareによって提供されるSNIの暗号化について説明します。ただし、cloudflare.comからのすべてのHTTPs URLは、TLS v1.3でのTCPパケット内のプレーンテキストです。

[ https://blog.cloudflare.com/encrypted-sni/][3]

ここにはすでにいくつかの良い答えがありますが、それらのほとんどはブラウザのナビゲーションに焦点を当てています。私はこれを2018年に書いています。おそらく誰かがモバイルアプリのセキュリティについて知りたいと思っています。

モバイルアプリの場合、アプリケーションの両端（サーバーとアプリ）を制御すれば、HTTPS を使用している限り安全です。iOSまたはAndroidは証明書を検証し、起こりうるMiM攻撃を軽減します（これがすべての唯一の弱点になります）。トランスポート中に暗号化されるHTTPS接続を介して機密データを送信できます。アプリとサーバーだけがhttps経由で送信されたパラメータを認識します。

ここでの唯一の「たぶん」は、クライアントまたはサーバーが、データがhttpsにラップされる前にデータを参照できる悪意のあるソフトウェアに感染している場合です。しかし、誰かがこの種のソフトウェアに感染している場合、データの転送方法に関係なく、そのデータにアクセスできます。

さらに、ReSTful APIを構築している場合、クライアントがブラウザーではない可能性があり、リンクをクリックするユーザーがいない可能性があるため、ブラウザーのリークとhttpリファラーの問題はほとんど軽減されます。

この場合は、ベアラートークンを取得するためにoAuth2ログインをお勧めします。その場合、唯一の機密データは最初の資格情報になります...おそらくとにかく投稿リクエストにあるはずです

あなたはすでに非常に良い答えを持っていますが、私はこのウェブサイトの説明が本当に好きです：https : //https.cio.gov/faq/#what-information-does-https-protect

つまり、HTTPSを使用して非表示にします。

• HTTPメソッド
• クエリパラメータ
• POST本文（存在する場合）
• リクエストヘッダー（Cookieを含む）
• ステータスコード