HTTPSでの暗号化はブラウザまたはシステムによって行われますか？
これは常識的な質問かもしれませんが、Googleで長い間検索した後、これに関するドキュメントを見つけることができません
ブラウザがHTTPsリクエストを行うと、データはその場で暗号化されますか？また、同じシステム上であっても、プロキシは暗号化された形式でデータを受信しますか？そのデータはプロキシ経由で（ネットワーク上ではなく同じシステム上で）正常に改ざんできますか？
ブラウザが暗号化/復号化を行う場合、そのように述べているドキュメントがあるかどうか私に知らせてください。または、暗号化/復号化が（要求がネットワーク内にある場合）トランスポートレベルでのみ、基になるSSLプロトコルによって処理されるかどうか。
[〜＃〜] https [〜＃〜] の「S」は「セキュア」（Hypertext Transfer Protocol Secure）の略で、通信プロトコルですTransport Layer Security（TLS）とその前身であるSecure Sockets Layer（SSL）を利用する安全な通信用。
TLS/SSLはレイヤー5（ セッションレイヤー ）で初期化され、レイヤー6（ プレゼンテーションレイヤー ）。 Webブラウザー、電子メールクライアント、インスタントメッセージングなどのほとんどのアプリケーションには、OSIレイヤー5、6、7の機能が組み込まれています。
HTTPSを参照する場合、HTTPプロトコルのコンテキストでのSSL/TLSの実装になります。次に、SSL/TLSが ブラウザー （およびWebサーバー）に実装され、HTTPSトラフィックの機密性と整合性（データの実際の暗号化）が提供されます。
ChromiumとFirefoxは、 [〜＃〜] nss [〜＃〜] と呼ばれるAPIを使用して、それぞれのブラウザーにSSL/TLSを実装します。
たとえば、Microsoft Windowsには、クライアントとサーバー間の認証を提供するためにSSL/TLSを実装する SChannel （セキュアチャネル）と呼ばれるセキュリティパッケージがあります。 Schannelは、たとえば、Active Directory環境内のMicrosoft Windowsクライアント/サーバーによって使用されています。
プロキシとデータの改ざんについては、使用しているプロトコルによって異なります。 HTTP（S）コンテキストに慣れるための良い例は、 Burp Proxy を見ることです。
ブラウザがHTTPSをどのように処理するかについては、良い答えがたくさんありますが、realの質問が解決されたかどうかはわかりません。
そのデータはプロキシ経由で（ネットワーク上ではなく同じシステム上で）正常に改ざんできますか？
ここでの答えはyesです。これは、次の2つの方法のいずれかで発生する可能性があります。
- ブラウザー自体が、悪意のあるプラグイン、拡張機能、またはアップデートによって侵害されています。
- システムは、ブラウザで使用される信頼されたルート証明書（OSで使用されるものと異なる場合があります）を変更したマルウェアに感染しています。
答えは...おそらくです。
https://を指定すると、ブラウザが暗号化を担当します。一部のブラウザーはOS提供のAPI（IEを見る）を使用）を使用しますが、他のブラウザー（Firefoxなど）は独自の暗号に沿ってトートし、OSが提供する暗号を完全に無視します。
改ざん防止はPKIによって保証されています。したがって、システムの信頼できる証明書ストアが破損した場合、すべての賭けは無効になります。たとえば、一部の企業は独自の内部署名CA証明書をインストールします。これにより、ブラウザーによるアラームを発生させることなく、安全なブラウザーセッションを中間者プロキシで仲介できます。ここでも、Windowsでは、IEまたはChromeを使用する場合、CA証明書はOSによって管理されますが、Firefoxには独自の個別の信頼できるCAリストがあります。
しかし、システムが危険にさらされている場合は、トーストしています。SSLでさえも、セキュリティを保証することはできません。これは、悪意のあるエージェントがチェーンのどこにでも自分自身を埋め込むことができるためです。おそらくネットワークレベルだけでなく、おそらくブラウザーでも、ディスプレイドライバーでも、またはキーストロークをリッスンしています...安全なものは何もありません。 今日のマルウェアの人気クラス があり、ブラウザに自分自身を挿入して、暗号化されたデータを読み取って変更しますbefore暗号化されて後復号化されます。たとえば、1つの目標は、オンラインバンキングサイトでの経験を少し変更して、銀行口座を空にし、すべてのお金を攻撃者に送金することです。
ブラウザは、アクセスするサーバーから提供されたSSL証明書/公開鍵を信頼している場合、データを暗号化します。次に、サーバーに渡され、2つのエンティティ間の暗号化された「セッション」を開始するために復号化されます。
優秀でわかりやすい説明 こちら 。
- ブラウザーは、SSL（https）で保護されたWebサーバー（Webサイト）に接続します。ブラウザは、サーバーがそれ自体を識別することを要求します。
- サーバーは、サーバーの公開鍵を含むSSL証明書のコピーを送信します。
- ブラウザーは、信頼されたCAのリストに照らして証明書のルートをチェックし、証明書の有効期限が切れておらず、取り消されていないこと、およびその共通名が接続先のWebサイトに対して有効であることを確認します。ブラウザーが証明書を信頼する場合、ブラウザーはサーバーの公開鍵を使用して対称セッション鍵を作成、暗号化、および返信します。
- サーバーは、プライベートキーを使用して対称セッションキーを復号化し、セッションキーで暗号化された確認応答を返信して、暗号化されたセッションを開始します。
- サーバーとブラウザーは、送信されたすべてのデータをセッションキーで暗号化します。
CA（認証局）に関する重要な情報： https://en.wikipedia.org/wiki/Certificate_authority
SSL暗号化は、ローカルプロキシがシステムに存在する場合でも、ブラウザ（またはSSLを使用するアプリケーション）によって設定されます。たとえば、ペンテストを実行しているときに、ローカルプロキシをセットアップして、ブラウザとエンドポイント間のトラフィックを復号化できるように独自の証明書を設定する必要がある場合などです。
ブラウザは復号化を通常どおり処理します。ただし、これにはいくつかの例外があります。プロキシはSSLを取り除くことができます（その場合、ロックアイコンは正常に表示されません）、またはクライアントが信頼できる証明書を使用してSSLを再署名し、ロックが引き続き表示されるようにすることもできますが、証明書に関する情報変更されました。本当に高度なセットアップでは、クライアント側ではなくサーバー側で使用されますが、SSLセッションでキーが生成されるため、サーバーの秘密キーにアクセスできる場合、SSL接続を実際に監視できます。
SSL/TLS仕様はover-the-wireプロトコルを規定していますが、クライアントの実装方法については何も述べられていません。通常、オペレーティングシステムカーネルは、暗号化されていない基本的なTCPソケットを提供します。SSLレイヤーを実装するために、ブラウザは暗号化ライブラリ（ OpenSSL 、SSLeay、 GNUtls または [〜＃〜] nss [〜＃〜] など）。したがって、 SSLサポートは通常、userspaceで、他のブラウザと同じプロセスで行われます。
SSLサポートが「システム」によって提供されると考えるかどうかは、状況によります。ブラウザは、暗号ライブラリに静的または動的にリンクできます。動的ライブラリ（またはDLL）をオペレーティングシステムと共に配布するか、ブラウザのベンダーが独自のライブラリのコピーを出荷する場合があります。
サーバー側では、状況はよく似ており、WebサーバーモジュールがSSLサポートを提供します（ユーザー空間で、残りのWebサーバーと同じプロセスで）。ただし、代替セットアップも一般的です。暗号化サポートはハードウェアアクセラレーションの場合があります。ロードバランサーなどのリバースproxyは、実際のWebサーバーの前に位置し、HTTPとHTTPSの間で変換する場合があります。その場合、データはコンテンツプロバイダーのネットワーク内を暗号化されずに移動します。
データの傍受と改ざんの懸念に対処するには：サーバーの秘密鍵にアクセスできる人なら誰でも簡単に送信を復号化できます。当然、ブラウザが信頼する認証局によって署名された証明書を提示するすべてのサーバーは、ホスト名が次の場合に限り、Webサイトをspoofできます。証明書はURLのホスト名と一致します。 （たとえば、Operaは、その Opera Mini 製品のプロキシを操作します。Opera Miniブラウザは、Operaのプロキシを介してすべてのトラフィックを流します。は、プロキシによって提示された証明書を完全に信頼します。したがって、ブラウザとプロキシ間のトラフィックは暗号化され、プロキシとコンテンツWebサーバー間のトラフィックは暗号化されますが、Operaプロキシを通過するすべてのデータを読み取ることができます。）最後に、ブラウザ（何らかの拡張機能またはプラグインメカニズムによって）または動的リンカー（LD_PRELOADのようなものを使用）またはブラウザの信頼できる証明書のリストを改ざんできる人また、データを傍受しますが、その時点ではクライアントの整合性が損なわれているため、意味のあるセキュリティは期待できません。
クライアントマシンにインストールされたプロキシは、実際に復号化HTTPSトラフィックを傍受できます。
ただし、これを行うには、独自の証明書を信頼されたルート証明書ストアに配置する必要があります。そうすることで、ユーザーはいくつかのセキュリティの課題を求められますが、簡単に回避することはできません。そのため、ユーザーが愚かなことを可能にするほど愚かでない限り、マルウェアがこの手法を使用することはまずありません。
非悪意のない目的でこの手法を使用するソフトウェアの優れた例は Fiddler -Web開発者向けのHTTP/HTTPSデバッグツールです。
「システム」とはどういう意味ですか？暗号化は一部のライブラリで行われる必要があります。これは、システムの一部と見なすことも、ブラウザの一部と見なすこともできます。 （ブラウザ自体も、実行可能ファイルを共有するすべてのユーザーのためにインストールされるという意味で、システムの一部です。）
セキュリティの細分性は、ブラウザ全体とそのコンポーネントが同じセキュリティコンテキスト（たとえば、独自のアドレススペースを持つオペレーティングシステムプロセス）にあることです。暗号化はそのプロセスで行われます。
平文データを傍受するには、ソフトウェアはブラウザのセキュリティコンテキストに違反する方法を見つける必要があります。これは通常、何らかの方法でスーパーユーザー権限を取得したコードの場合、大まかなセキュリティポリシーしかないオペレーティングシステムで可能です。
例えば。 Unixライクなオペレーティングシステムでは、ptraceシステムコールを使用してプロセスにアタッチし、その実行を一時停止して再開したり、システムコールを監視したり、メモリを調べたり変更したりできます。
フォームに入力したキーストロークなど、ブラウザに入ってくるデータは、他のセキュリティコンテキスト、つまりオペレーティングシステムカーネルにキーボードドライバを含むものに由来します。また、ドライバを通過するデータにアクセスできる特権プログラムからも攻撃される可能性があります。
ただし、同じマシンで実行されているHTTP/HTTPSプロキシ（プロセスをのぞく悪質なスーパーユーザープログラムとは対照的）は、プレーンテキストトラフィックにアクセスできません。プロキシを通過するのは、暗号化されたHTTPSプロトコルです。