証明書のないSSL/TLS

Question

私は、最終的には安全なファイル転送を可能にするペットプロジェクトに取り組んでいます（これ以上のことはありますが、それ以外は特に重要ではありません）。私はOpenSSLライブラリを使用したいと思っています。なぜなら、これは最も完全な無料の暗号ライブラリであるようです（そして、SSL/TLSに加えて、基本的な対称暗号化とハッシングのサポートが必要です）。

セキュリティー・スキームと同様のをSSHに実装する予定です。基本的に、ユーザーはTLSv1（SSLv3.1）で自分のコンピュータに接続します。私は接続がセキュリティに関係なく成功するようにしたいと思います。次に、ユーザーが使用した公開キー（証明書全体ではない）を検査できるようにします。そのキーは既知の公開キーと比較され、一致した場合、ユーザーは特定の一連のコマンドにアクセスできます。一致しなかった場合は、接続を使用して自分の公開鍵を自分のコレクションに追加するために接続を使用するオプションがありますが、それ以外の場合は自分のサービスにアクセスできません。

私はここで証明書を特に必要としません。すべての証明書の詳細をスキップして、生の暗号化キーでしか作業できない場合は、はるかに簡単です。これは、このモデルがほとんどのSSL/TLS接続で使用されている階層モデルではなく、web-of-trustモデルに準拠しているため、CAまたは署名付き証明書は必要ありません。

残念ながら、ほとんどのOpenSSLのドキュメントは、まったく存在しません。私が見つけたすべての関連記事は、 "標準" SSL/TLS接続を設定することで占められているようです。サーバーの証明書は一連のルート証明書まですべて検証されます。これは便利ですが、これらの非伝統的なSSL接続をどのように稼働させるかを理解することは難しいです。

誰でも、これを達成する方法を理解するのに役立つ記事やドキュメントを提案できますか？

（OpenSSLの使用は石で設定されていません。これを実行するためのより良い方法があれば、別のライブラリに切り替えることができます。また、SHA-512と対称暗号[AES] Linuxをターゲットにすることを目指していますが、最終製品がWindowsに移植されていれば友だちも使えるのでいいです）。

Answer 1

（私はコメントとしてこれを入れているだろうが、それは少し長いです）ユージンの答えに拡大するために...

Xに固執、FOAF+SSL project（後でWebIDを改称）で物事のこの種をやりましたほとんどのSSL/TLSスタックはそれらを念頭に置いて設計されているため（APIがこれを反映しているため）、.509証明書は実装を容易にします。

前回私はFOAF + SSLをチェックしましたが、クライアントがサーバー証明書をチェックするための従来のPKIチェックはまだ行われていました。 SSHに似た別のオプションは、初めて公開鍵/証明書を受け取り、変更時にユーザに警告することです。とにかくSSHの仕組みは多かれ少なかれです（特に、初めて実際にバンドの指紋を確認する人はほとんどいないと思います）。ただ、クライアント証明書の使用方法を（これのいくつかは同様の方法で、サーバーの本命に適用することができますが）を考慮すると

：

• ほとんどのサーバライブラリは、X.509証明書を処理することができるように見えるが、あなたを聞かせて彼らが検証される方法を変えなさい（例えばJavaではX509TrustManager）。
• クライアント証明書には、別の方法で確認するまでは信頼できませんが、いくつかの追加情報（主体DNや主体別名など）を埋め込むことができます）は、（a）ユーザが自分の証明書を整理し、（b）検証者に何を探すべきかを知らせるヒントを与えるのを助けることができる。裸の公開鍵は管理が難しい場合があります。
• 多くの既存のクライアントツール（特にブラウザ）は、SSL/TLSクライアント認証を行うときにX.509証明書を使用します。 PKIからの証明書ではなく、自己署名X.509証明書を使用するようにクライアントを構成するには、それほど多くのことを行う必要はありません。 （OpenPGP for TLSをサポートするツールはごくわずかですが、それをクライアント証明書の形式として使用できるかどうかはわかりません）
• 外部チェックなしで証明書を信頼できないため、自分が署名しているかどうか（つまり、発行者とサブジェクトが同じかどうか）は関係ありません。少なくとも、ユーザーがあなたに同意しない証明書を送信しないと仮定すると（したがって、それ自身の鍵で密封される）。その結果、証明書を簡単に発行するサービスを構築することができます。たとえば、ブラウザ内キー生成は、opensslまたはkeytoolコマンドを使用したくないユーザーにとって便利です。 Hereは、ユーザーが望むSANで証明書を発行するサービス例です（FOAF + SSL/WebIDプロジェクトでチェックすると最新のバージョンが存在する可能性があります）。そのようなサービスが使用するプライベートキーまたは発行者名はほとんど問題になりませんが、ブラウザは従来のPKIに基づいて設計されているため、実際に自己署名証明書を使用することは容易ではありません。

特定のクライアント証明書を要求する際にも問題があります。 TLS 1.1の仕様では、空のcertification authorities（RFC 4346参照）が明示的に許可されていましたが、TLS 1.0は対象に対してサイレントでした。実際には、TLS 1.0の場合でも、ほとんどのクライアントツールは空のリストに満足しているようです（より多くの選択肢を提供するだけです）。システムの証明書を容易に識別できるようにするには、実際に同じ秘密鍵で署名されていなくても、これらの証明書すべてに同じ発行者DNを使用できます（署名は無視されるため）。

Answer 2

自己署名証明書を使用する - これは「生」キーと同じですが、 （opensslで自己署名証明書を受け入れるかどうかについては、this questionを参照してください）。