証明書のピン留めとE2E暗号化
非対称暗号化を使用してhttps接続のコンテンツを保護するために何らかの公開鍵を交換するいくつかのAPIがあることがわかります。これに追加の利点はありますか？私の知る限り、証明書のピン留めがあるtls接続を途中で実行することは不可能であるべきです。
エンドツーエンドの暗号化の利点は、コンテンツがエンドユーザーから別のエンドユーザーに送信されたときに明らかであり、バックエンドサーバーはコンテンツを読み取ることができません。しかし、データをバックエンド（エンドクライアントからエンドバックエンド）に送信するだけの例をいくつか見ましたが、ある種の非対称暗号化が適用されました。
たとえば AWS S を使用すると、クライアントはデータを送信する前に暗号化できます。アカマイもコンテンツを暗号化する可能性があることをどこかで読みました。また、コンテンツを暗号化するためにカード/キーを使用する必要がある機関もいくつか見ました。
だから私の質問に戻りますが、実際には何らかの手段（RSAまたは何らかのデバイス）を使用してコンテンツを暗号化し、証明書をピン留めしてTLS経由で送信することの利点はありますか？
非対称暗号化を使用してhttps接続のコンテンツを保護するために何らかの公開鍵を交換するいくつかのAPIがあることがわかります。これに追加の利点はありますか？私の知る限り、証明書のピン留めがあるtls接続を途中で実行することは不可能であるべきです。
TLSプロトコル全体がどのように機能するかを読んでください、それはここで入手できる素晴らしい記事です： SSL/TLSはどのように機能しますか？
簡単に言えば、公開鍵は、対称鍵（プロトコルハンドシェイクの一部として導出された鍵）を使用して暗号化されたコンテンツを認証できるようにするために使用されます。
証明書のピン留めにより、中間者攻撃は常に軽減されるとは限りません。たとえば、中間の攻撃者がピン留めについて何も触れていない証明書を返す前に、ブラウザがサイトにアクセスしたことがない場合。
エンドツーエンドの暗号化の利点は、コンテンツがエンドユーザーから別のエンドユーザーに送信されたときに明らかであり、バックエンドサーバーはコンテンツを読み取ることができません。
いいえ。サーバーに到着したとき、理論的にはそのサーバー上の何でもデータを見ることができるデータを保護するだけです。
しかし、データをバックエンド（エンドクライアントからエンドバックエンド）に送信するだけの例をいくつか見ましたが、ある種の非対称暗号化が適用されました。
たとえば、AWS S3では、クライアントがデータを送信する前に暗号化できます。アカマイもコンテンツを暗号化する可能性があることをどこかで読みました。また、コンテンツを暗号化するためにカード/キーを使用する必要がある機関もいくつか見ました。
S3では、クライアント側の非対称暗号化が可能です。つまり、ローカルマシンがAWSに送信する前にデータを暗号化しています。これは、AWSでさえも、ファイルの内容を表示できることを意味します。これは、転送中のデータではなく、保存中のデータを保護するためのものです。
だから私の質問に戻りますが、実際には何らかの手段（RSAまたは何らかのデバイス）を使用してコンテンツを暗号化し、証明書をピン留めしてTLS経由で送信することの利点はありますか？
これは、リスクの受け入れとコンプライアンスの要件によって異なります。しかし、はい、データの暗号化はそれ自体ではデータを認証しません。あなたが誰かに暗号化されたファイルを送るならば、彼らはそれが実際にあなたから来たことをどうやって知るのですか？誰かがあなたの鍵を使用した可能性があります。 SSL/TLSは接続を暗号化するだけでなく認証も行うため、通信を開始したエンドポイントと実際に通信していることがわかります。証明書のピン留めにより、前回と同じ証明書を確実に取得できるため、中間者攻撃に関与する可能性が低くなります。
私はこの問題を重ねて好きです。ピニングを使用して特定のサーバー証明書のみを信頼することを保証するためにTLSを使用し、レイヤー（セッション/トランスポート）が最上位であることを確認し、サーバーのキーペアの否認防止を保証します。例えば。信頼するキーペアは、接続先のキーペアであり、従来の信頼チェーンの使用法（署名CAの検証）であることがわかっています。ピン留めされた証明書のチェーンをチェックすることは重要ではないと言えますが、モデルを大幅に変更することはないため、ここではそれを無視します。
証明書自体は、セッションのTLS終了を提供するサービスによって必要とされます。開発/個別の使用以外のほとんどの実装では、エンドユーザーからの動的要求に応答するアプリケーションサーバーとは別に存在するTLS接続を終了するWebサーバー/ LBがよく見られます。
アプリケーションサーバー/処理では、TLSトンネル内のデータが送信されますが、証明書をピン留めすることで信頼している同じ人物/組織によって制御されるとは限りません。セッションレイヤーの上（データ自体）に追加の暗号化を追加すると、その一連のキーがTLSサーバー証明書とは別に制御される場合（たとえば、独自の対称キーを使用してデータを暗号化した場合）、追加の機密性が提供されます。
非対称暗号化について話している場合は、別のキーペアを使用してクライアント側でIDを確認できます（クライアントに公開側面が宛先サーバーと共有されているキーペアがある場合）、秘密キーを使用してデータを暗号化して、 TLSトンネル内であなた（クライアント証明書を制御する）の否認防止を実証し、トランザクションの機密性とサーバーの否認防止を可能にし、検証後、クライアントの否認防止。