私はクライアントがサーバの前に認証するセキュリティプロトコルが必要です。これはプライバシーの問題のために必要です。知られていない当事者に、彼らが誰に知り合わなければ誰に接続しているかを知らせたくない。 TLSプロトコルでは、サーバーが証明書を送信して、この可能性を排除します。自分のプロトコルを実装することは悪い考えであることを知っています。しかし、選択肢はありますか？私。他の順序で証明書を送信するようにプロトコルを変更する方法はありますか？ TLSへのWikipideaの参照：http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshakeクライアントを最初に認証するにはどうすればよいですか？
クライアントとサーバーの役割を逆にすることができます。
通常、クライアントはconnect()（そしてSYNを送信した）エンドポイントであり、サーバはaccept()（SYNを受け取り、SYN | ACKを送り返した）エンドポイントです。しかし、いったん接続が確立されると、クライアントのソケットとサーバーのソケットとの間に差はなくなります。
あなたが使用している場合、たとえば、OpenSSLは、あなたが正常に成功したconnect()後SSL_connect()を呼び出して、あなたが正常に成功したaccept()後SSL_accept()を呼び出します。しかし、それを裏返して、クライアント側でconnect()の後にSSL_accept()と電話し、サーバ側でaccept()の後にSSL_connect()と呼んだら、OpenSSLは違いを知らないでしょう。クライアントはTLSサーバーとして動作し、最初に自身を識別します。
それは、クライアントがサーバーの資格情報をチェックすることを許可しないでしょうか？あなたは少し混乱して、ごめんなさい、もう少し説明できますか？ありがとう！ – chacham15
サーバは、通常のTLSの場合と同様に、クライアントが最初に完了した後で証明書を提示することができます。 – Celada
+1。 [TLS RFCが示す]（http://tools.ietf.org/html/rfc4346#appendix-B）： "* client *： サーバとのTLS接続を開始するアプリケーションエンティティ。クライアントが の基本的なトランスポート接続を開始したことを意味するものではなく、サーバとクライアントの間の主な操作は で、サーバは と一般的に認証されています。 – Bruno
なぜこれをやろうとしていますか？本当にあいまいな自己署名証明書を作って、代わりにその証明書を信頼することができますか？ – jglouie
@jglouie問題は、証明書に識別可能な情報（証明書の目的）が含まれており、任意の人物がユーザーを特定できないことです。 – chacham15
偽の識別データを自己署名証明書に入れることができます。そのアプローチはうまくいくのでしょうか、あるいはあなたのCAがすでにクライアントから信頼されている「本当の」証明書が必要ですか？ – jglouie