独自のセキュリティメカニズムを導入する方法-SSLを回避する
私は、SSLを使用するのではなく、独自のセキュリティメカニズムを実装することを検討しています。SSLが '絶望的に壊れている' であり、また興味深い演習であるためです:)
これは、クライアント/サーバーインターネットアプリケーション用です。
警告-私はセキュリティの専門家ではありません-セキュリティについて読んでいるだけです。
クライアントアプリケーションも構築するので、実装の両側を制御できます。
SSLの問題
SSLで私が目にする主な問題は、ハンドシェイク段階での公開鍵の交換と、これを傍受している中間の男によるものです。 SSLは、メッセージ署名や証明書などを使用してこの問題を回避し、クライアントのサーバーの公開鍵を検証します。しかし、偽造された証明書を持つ攻撃者は、これを回避できます。
Workaround
安全な公開鍵交換のこの問題のため、サーバーの公開鍵を交換する必要がなく、すべてのクライアントアプリケーションに「既知の」サーバーの公開鍵を組み込むことで、これを回避できると思います。 3072ビットのRSA鍵を言います。
実装
- したがって、各通信セッションの実装は、クライアントが公開/秘密RSAキーペアを生成することになります。
- クライアントは新しい公開鍵をサーバーの公開鍵で暗号化し、サーバーに送信します
- サーバーはメッセージを復号化してクライアントの公開鍵を発見し、これを使用してクライアントへの応答を暗号化します
- クライアントはサーバーの公開鍵で暗号化されたトラフィックをサーバーに送信し続けます
- クライアントから送信された各メッセージには、ヘッダーにも含まれます：
- サーバーの公開鍵で暗号化されたクライアントのユーザー名
- 暗号化されていないクライアントメッセージのハッシュ-このハッシュを生成するための入力として使用する、[クライアントユーザー名+レルム+クライアントパスワード]の別のハッシュ
観察
- サーバーは、まず秘密鍵を使用してメッセージを復号化し、次にデータベースに保存した[クライアントのユーザー名+領域+パスワード]のハッシュを使用して暗号化されていないメッセージのハッシュを計算することにより、クライアントの身元を証明できます。
- トラフィックは双方向で暗号化されているため、中間者はトラフィックを監視できません
- 真ん中の男は有効なメッセージハッシュを生成できないため、クライアントを装うことはできません。
- 真ん中の男は、最初のメッセージを復号化できないため、クライアントへの応答を暗号化するクライアントの公開鍵を見つけることができないため、サーバーを装うことはできません。
- クライアントパスワードを入力として使用したハッシュは暗号化されていないメッセージに対するものであるため、クライアントのパスワード自体はブルートフォースの精査から保護されているため、攻撃者はこのハッシュに対するブルートフォース攻撃を開始する前に、まずメッセージを復号化する必要があります。
私はセキュリティの専門家ではないので、セキュリティについてもっと知っている人がこのアプローチの穴を見つけたり、それが良いかどうかを確認したりできると期待しています。また、3072ビットのRSA鍵が壊れることなく時の試練に耐えることができれば。
ありがとう！
最終的にはSSLを使用することにしました。最終的にはSSLが最も単純なアプローチになったためです。もう1つのアイデアはWCF側ではうまく機能していませんでした。
私はこれをcode-projectに書いて、他の人が同様の問題を抱えるのを助けます。
http://www.codeproject.com/KB/WCF/WCFJsonRestHttpSecureRole.aspx
私はまだ自分の公開鍵のみを信頼し、CA鍵は信頼しない方法を理解する必要があります-as3cryptolibを見ると、TLSConfigのCAStoreプロパティで可能であるかもしれません http://code.google.com /p/as3crypto/source/browse/trunk/as3crypto/src/com/hurlant/crypto/tls/TLSConfig.as
SSL/TLSを、X.509証明書と公開鍵インフラストラクチャ（PKI、 RFC 528 ）と組み合わせた最も一般的な使用パターンと混同しています。
（アクティブなMITM攻撃を防ぐために）サーバーサイトを認証してTLS接続を保護することは非常に重要ですが、TLS仕様では、実際にはX.509証明書を使用することを義務付けていません。
@jathanismが言ったように、自己署名X.509証明書を使用することにより、階層型PKIに依存しないことを選択できます。他の方法でサーバー証明書の信頼を確立する必要があります。
さらに、TLSは OpenPGP証明書 、 Kerberos または 事前共有鍵 でも使用できます。
TLS自体には、私の知る限り、既知のバグはほとんどありません。再ネゴシエーションのバグ（CVE-2009-3555）がありました 修正されました （最近では、特定のブロック暗号にも特定の問題がありました。より良い暗号スイートを選択するか、アップグレードすることで修正できます）新しいバージョンのTLSへ）。
あなたが話している（そしてしばしばマスコミで議論されている）問題は、PKIに関連する傾向があります。つまり、リモートパーティへの信頼を確立する方法です。これをどのように行うかは、TLS仕様自体では規定されていません。
より良い方法を見つけたい場合は、必ずいくつかの調査を行ってください。ただし、この部分に焦点を当て、SSL/TLSと暗号化の側面のみを残すことをお勧めします。 PKIとその代替策に関する最大の問題は、技術的な問題ではなく、管理上の問題であることがわかります。
リモートパーティを認証するもう1つの側面は、目的のパーティと話していることを確認することです（つまり、 ホスト名の検証 ）。
両側を制御できる場合は、自己署名SSL証明書を使用してください。できました。ルート認証局を信頼していないため、アーキテクチャの内部知識がなければ、暗号を解読することはほとんど不可能になります。
SSLは「絶望的に壊れる」メカニズムではなく、仕様バージョンのSSL v3.0（およびSSL v2.0）です。
SSL v3.0以降、仕様はTLSに名前が変更されました。 TLS 1.0は依然として安全と見なされています。 TLS 1.2の使用をお勧めします。
そして、ええ、他の人が言ったように、あなた自身のものを転がすことさえ考えないでください。十分な暗号化を知らなかった誰かが自分でロールバックしようとすることが、初期のWiFi暗号化が数秒または数分で解読される可能性がある理由です。彼らは弱いアルゴリズムから始め、それから実装の問題を通してそれをさらに弱めました。