他の手段で既に交換されたサーバーの証明書を使用して、クライアントがサーバーへの SSL 接続を確立することは可能ですか?
ポイントは、クライアントで既に証明書を使用して接続を暗号化し、それを提供するためにサーバーに依存する必要がないことです。サーバーには、クライアントが使用する証明書の秘密鍵がまだあります。
この質問は言語固有のものではありませんが、python および twisted に固有の回答を歓迎します。
他の手段で既に交換されたサーバーの証明書を使用して、クライアントがサーバーへの SSL 接続を確立することは可能ですか?
ポイントは、クライアントで既に証明書を使用して接続を暗号化し、それを提供するためにサーバーに依存する必要がないことです。サーバーには、クライアントが使用する証明書の秘密鍵がまだあります。
この質問は言語固有のものではありませんが、python および twisted に固有の回答を歓迎します。
SSL/TLS の証明書は認証にのみ使用され、暗号化自体はハンドシェイク中にネゴシエートされた共有キーによって行われます。
証明書を使用する場合は、少なくとも SSL/TLS サーバーに証明書 (TCP クライアントの場合もあります) が必要です。接続を確立するときに、クライアントとサーバーの役割を実際に入れ替えることができます。つまり、SSL/TLS サーバーは TCP サーバーである必要はありませんが、TCP クライアントになることができます。仕様用語集の定義を参照してください。
client The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.
ただし、そうすると問題が発生する可能性があります。従来の SSL/TLS 接続のサーバーがリクエストが MITM を介したものかどうかを検出できないのと同じように (クライアント証明書認証なしで、サーバー証明書を確認するのはクライアントの責任です)、TCP クライアントを SSL/ TLS サーバーは、TCP クライアントが意図した TCP サーバーと通信していることを認識するのを困難にします: サーバーは実際には MITM である可能性があります。これがニーズに合っているかどうかを検討する必要があります。
server_side
Python では、 のパラメーターを使用して SSL/TLS ソケットの方向を選択できるはずですssl.wrap_socket
。
サーバーには、クライアントが使用する証明書の秘密鍵がまだあります。
これはまったく意味がありません。秘密鍵は、証明書が発行された当事者によって秘密にされるべきです。
おそらく、代わりに事前共有鍵メカニズムを求めているでしょう。
TLS では、サーバー (listen
接続側) は常に証明書を必要とします。クライアント側の証明書は、ピア認証にのみ使用できますが、チャネル暗号化には使用できません。
また、何らかの方法で証明書を検証するためのインフラストラクチャがなければ、接続を単純に「暗号化」することはできないことにも注意してください (たとえば、証明機関や信頼データベースを使用)。証明書の有効性の検証を行わない暗号化は、アクティブな敵対者に対して有効ではありません (詳細については、「man in the middle 攻撃」を Google で検索してください)。