WebSocketの証明書のピン留め
ネイティブライブラリとプラグインを使用してモバイルデバイスで実行されているクライアント側のアプリから発信されたHTTPS接続の証明書ピン留めの多くの実装を見てきました。
このような証明書ピン留めの実装がWebSocketで利用できるかどうか知りたいのですが。クライアント側（たとえば、モバイルデバイスやWebブラウザー）で、実際にWebSocketの証明書ピンを実装できますか？
そのようなアプローチが利用できる場合、理想的にはリソース/記事/コードスニペット/ライブラリへのリンクを使用して、説明があれば本当にいいでしょう。
安全なWebSocketの保護
セキュアWebsocketは標準のHTTPSリクエストとして開始され、サーバーとの有効なHTTPS接続を確立できる場合にのみ接続します。その結果、WebSocketは、クライアントが最初にWebSocket接続を確立しようとしたときにサーバーが応答ヘッダーに設定した公開鍵のピン留め、厳密なトランスポートポリシーなどを自動的に尊重します。
したがって、Webブラウザーの場合は、標準のPublic-Key-Pinsheader を提供するだけです。私はそれがモバイルクライアントでどのように機能するかは言えませんでした。プラットフォームごとに異なる場合がありますが、ブラウザと同じセキュリティヘッダーに従うだけの人が多くても驚くことではありません。
警告
ただし、公開キーのピン留めを実際に気にしたくない場合があることに注意してください。サポートが弱まっているように見えるか、すでに gone になっているようです。公開キーのピン留めの問題は、- 企業で発生した のように、文字どおりユーザーを固定できない方法でWebサイトから締め出すことができる唯一のセキュリティ対策の1つであることです。
WebSocketについて
WebSocket接続を介して要求/応答ヘッダーを設定できないという事実を論じている記事にリンクしました。これは本当ですが、それでも私の上の答えは変わりません。記事は実際には別のことについて話していますが、誤解の一般的な原因です（最初のWebSocketサーバーとクライアントで認証を有効にしたとき、私も同じ質問に出くわしました）。説明するには、WebSocketリクエストのライフサイクルを理解することが重要です。
- クライアントは、特別な
UPGRADEヘッダーを使用して標準のHTTPリクエストをサーバーに送信します。 - サーバーはヘッダーを確認し、新しいプロトコルにアップグレードする要求を受け入れたことをクライアントに通知する応答を送信します
- 正式にアップグレードされたため、クライアントとサーバーの両方が元のTCP=接続を開いたままにして、必要に応じてデータを直接送受信します。
あなたの記事はこのプロセスのステップ3に言及しています。 WebSocket接続が確立されると、HTTP要求が送信されなくなるため、要求ヘッダーまたは応答ヘッダーを送信できなくなります。代わりに、クライアントとサーバーは、TCP接続を介して、必要な形式でデータを直接交換します。
ただし、WebSocket接続を確立する最初の試みは、標準のHTTPリクエストを介して行われ、標準のHTTPリクエストを適切に確立する必要があります。その結果、ブラウザーは、最初に接続を確立するときに、Websocketサーバーによって送り返された応答ヘッダーを引き続き尊重する必要があります。そして実際、サーバーはプロセスのそのフェーズで追加のヘッダーを送り返すことができます。