AJAX/PHPを使用してSSLプロトコルを模倣するaSSLプロジェクトに精通している方もいるかもしれません。キーにはRSA 512または1024、実際のデータにはAESを使用します。概念的には印象的に見えますが、渡されたキーを明らかにする可能性がある/明らかにする可能性のある明らかなインターセプトが見られないかどうかを知りたいと思います。ご存じのとおり、JSからPHP暗号化手法は、キーがオープンでクライアント側に渡されるため、通常は役に立ちません。これはより高度なアプローチのようです。
手順は次のとおりです。1.ブラウザがサーバーを呼び出してプロセスを開始します。
サーバーは、RSA係数と公開指数を返します。
ブラウザはランダム交換の128ビットキーを生成し、サーバーの公開キーを使用してそれを暗号化し、暗号化された交換キーをサーバーに渡します。
サーバーはこの暗号化された128ビットの交換キーを受信し、秘密キーで暗号化を解除し、結果に問題がなければ、セッション継続時間を返します。
ブラウザはセッション継続時間を受け取り、接続を維持するためにタイムアウトを設定します。
プロジェクトのURLは次のとおりです。 http://assl.sullof.com/assl/
これに潜在的な可能性がある場合、ハンドシェイクをさらに改善し、クライアント側をさらに保護する方法についていくつかのアイデアがあります。
中間者攻撃からどのように保護しますか?私が集めたものから、それはまったくありません(実際にできる方法を考えることはできません)。それは完全に役に立たないにします。
SSL/TLSが機能するのは、接続が安全であるとソフトウェアが信頼しているためです(通常はブラウザ)。接続を攻撃者から信頼できることを通知するコードをダウンロードすると、すべての賭けが明らかに無効になります。
ドキュメンテーションはかなり薄いので間違っているかもしれませんが、それは(礼儀正しく)全然よく見えません。
私が知っている、私が知っている、私が知っている-皆さんがphpにJavaScriptについて言及した2番目は、皆さんが目を転がしましたが、真剣に最初に見てください-これは少し異なります。
いいえ、残念ながら違いはありません。 有害と見なされるJavascript暗号化 は、一般的な問題の概要を示します。
いくつかの問題は、不適切な実装(PRNGなど)に関係しています。これはJavaScript自体の欠陥ではありません(おそらく一部のNode.js実装の方が優れている可能性があります)が、ブラウザーの実装(これを実際に信頼することはできません)。
その他の問題は、JavaScriptの使用方法にとってより根本的なものです。ブラウザでSSL/TLSをエミュレートすることを目的とするJavaScriptライブラリの問題は、保護するコンテンツと同じシステムの一部として、またはその一部として配信されるJavaScriptコードに常に依存することです。その時点から、MITMとの戦いは失われます( (自身のFAQ too を参照)を参照)。
さらに、SSL/TLSの基本的なポイントは、リモートパーティのIDの検証です。これは、(a)一連のトラストアンカー(CA証明書)が既に配置されていること、および(b)信頼がどのように評価されたかを一貫して表示する方法(ブラウザー内のGUI統合、ロック記号などを示す)に依存しています。これらの要素は、単にWebページに属することはできません(それ以外の場合は、誰でもページのロックアイコンを提供できます)。
最初に頭に浮かぶのは弱いPRNGエントロピーです。そして、遅いかもしれません...そして、SSLを使用しないのはなぜですか?