SSL / TLSを置き換えるには？
私はNGO（非政府組織）のウェブサイトを作成する必要があります。彼らはプロバイダーからの最小限のオプションしか持っていないため、SSL/TLS（ほとんどHTML/PHP/MySQL/JSのみ）を使用できません。
サーバーとの間でやり取りされるデータはそれほど機密性が高くありませんが、パスワード、名前、およびアドレスがWeb上で明確に送信されることを望んでいません。
RSAでAPI関数を呼び出すJavaScript内のデータを暗号化することを考えました（私はエキスパートではありませんが、 このlib はかなり効率的です）、しかし私は赤 暗号にJavaScriptを使用しないことを強くお勧めする記事 （私はフランス語で、おそらくすべてが正しくないが、メインポイント）。
それでは、ネットワークを介してデータを暗号化するために何を使用する必要がありますか？
JSが本当に悪い考えではない場合、サーバーにlibをインポートすることを除いて、このサーバーで使用できるテクノロジーで最大の安全性を確保するために何ができますか（もう一度、HTTPSはありません）。別のサーバーからのインポートに依存していませんか？
SSLなし、セキュリティなし現実の世界の事柄はめったに単純ではありませんが、ここではそうです。これは次のように簡単に確認できます。Javascriptで行うことはすべて、サーバーによって送信されるJavascript で行われます。データを見る立場にある攻撃者は、自由にデータを変更することもできます（たとえば、WiFiをスパイする最も簡単な方法は、独自の偽のアクセスポイントを実行することです。その後、すべてのデータを変更することができます） ;したがって、このような攻撃者は、Javascriptベースのソリューションを思いついただけで削除または変更し、それを無効にすることができます。または、フックを also に追加して、パスワードを平文で追加のパラメータとして送信します。
これで、 could がクライアントブラウザで「安全なJavascript」を取得した場合でも、Javascript暗号が引き起こすすべての問題に遭遇します。 。しかし、これは上記で説明した根本的な欠陥と比較して、二次的な考慮事項にすぎません。SSLがないと、クライアントブラウザで実行するコードができないかどうかを確認できます。
非SSL Webサイトでパスワードを安全に処理することは、ティースプーンとさびたバールだけで安全に脳の手術を行うことと同じです。しないでください。 Webサイトに流れる機密データ（名前やアドレスなど）がある場合は、適切な保護メカニズムを適用する必要があります。データが機密ではない場合、なぜパスワードが必要なのでしょうか。
私見乱数発生器はここであなたの心配の最小です。暗号化を呼び出すコードは平文で送信されるので、誰かが対話をMITMするのは簡単です。
サービスが暗号化によって提供されるセキュリティのレベルを必要とし、ウェブサイトによって配信される場合、サービスは[〜＃〜] must [〜＃〜] HTTPSを使用します（理想的には、secure +のような関連するすべてのセキュリティ関連物） httponly cookieとHSTS）。
これを回避する唯一の方法は、HTML5アプリを作成することです（コードが頻繁にダウンロードされない場合）。ただし、これにも重大な欠点があります。
すでに述べたように、最善の解決策は、httpsを許可する実際のWebホスティングプランを取得することです。これは高すぎるものであってはならず、実際には 無料のプロバイダー を見つけてこれを提供することも可能です。
それができない場合、あなたのユースケースは何ですか？あなたはあなたのウェブサイトのために一連のユーザーグループを念頭に置いているようです。その場合、サブスクリプションベースのイベント通知サービスをインターネット上のランダムな人々に提供するだけではない場合は、別のチャネルでの「安全な」接続の基盤を提供することを検討してください。
別の信頼できるソース（CDを郵送で郵送し、電子メールで通知する、単にデジタル署名された電子メールの添付ファイルとしてソフトウェアを送信するなど）でコードをマシンに取得すると、事前に-暗号化公開鍵を使用してソフトウェアをロードします。
その後、サーバーが公開鍵で暗号化された詳細を十分に復号化したかどうかを判断するコードがクライアント上に存在するため、安全でない接続方法（httpなど）を介して安全な接続をネゴシエートできます。結果として、「プレーンテキスト」のhttpアプリケーションデータのストリームが生成され、アプリケーションデータ自体が暗号化されるというしわがあります。
これは多くのトラブルであり、非標準的な方法です。アドバイスを提供しようとした人がほとんどいないため実装に問題が発生し、信頼性を確認した人がほとんどいないためセキュリティに問題があります*。
代替チャネル自体にセキュリティの問題がある可能性があります。メールが傍受される可能性はありますか？詐欺師が組織になりすまして、独自の「安全な」バージョンのソフトウェアを送信する可能性はありますか？ユーザーは、送信するメールのデジタル署名をチェックするのに十分な知識がありますか？これらはすべて、実装する方法だけでなく、どのような質問をする必要があるかについてのガイダンスが少ないため、リスクとして受け入れるか、リスクとして受け入れるか、または新しいソリューションで軽減しようとする必要があるすべての懸念事項です（尋ねる必要があります）これら3つだけではありません！）.
NGOの管理者と話をするときは、次の条件で状況を概説することを検討してください。
- 後者の方法は重大なリスクを伴い、ホスティングの費用を支払うよりも実装に多くの時間を費やすことになります-特にサーバー（またはサーバーのキーペア）が変更され、継続的に新しいものに配布される場合、プログラムを更新する必要があります初期展開後のユーザー。
- 何もせず、アドレスと名前（および場合によっては電子メールアドレス）を使用してhttp経由でパスワードを使用することは、情報漏えい（およびその可能性）が発生すると、広報災害となり、重大なリスクとなります。これは、人々がパスワードを再利用し、あなたの悪い習慣がその後の違反につながる可能性があるという事実によってさらに悪化します。
- あなたはそのような状況で重要な考えを与えられており、ステップ4で概説された解決策を提案するだけではありません。 ）。ステップ1と2で概説されている代替の（複雑で複雑な場合）ソリューションを提案できることは、このデューデリジェンスが実施されている証拠です。
- これに基づいて、継続的なコストが低い（またはない）httpsホスティングは、コストが最も低く、リスクが最も少ないアプローチです。
*ジョナサン・グレイが理由に入ると、安全なシステムのコーディングで問題が発生します 彼の回答 、「 TLSは、より本質的なシステムでもあります。」
まずホストを交換してください。
無料のCAのおかげで、SSL証明書の取得がこれまでになく簡単になりました。 LetsEncrypt たとえば、ドメイン名を所有している場合は、無料のSSL/TLSドメイン検証証明書を自動的に提供します。 StackzOfZtuffの答え に、その機能に関する詳細な説明があります。
コミュニティサイト に設定する方法については、FAQとヘルプフォーラムがあります。
JSの問題は、乱数の生成です（これは、最新の暗号化のセキュリティに不可欠です）。これを解決するのに役立つ既存のライブラリーが利用可能ですが、ライブラリーがcrypto.getRandomValuesを使用すること、および人間の入力（マウスまたはキーボードのアクティビティーなど）からエントロピーを取得する機能を確実に使用する必要があります。ただし、これは特にモバイルデバイスにとっては厄介です。特に、ハードウェア自体が安全な乱数を生成する能力が低いことを考えると、.
RSAについてもう1つポイントを追加したいと思います。それを使用して暗号化できるのは少量のデータのみであり、データ量は使用されるキーの長さに比例します。それだけでなく、RSAは低速です。適切な量のデータが必要な場合、またはサーバーに複数の要求を行う場合は、サーバーの公開鍵を使用してクライアント側のJSでランダムキー（CSPRNG）を暗号化し、対称暗号化にそのキーを使用することをお勧めします。
編集：TLSはまた、あらゆる種類の攻撃から保護するために非常に一生懸命働く、より本質的なシステムです。 TLSが効果的に保護しない唯一のタイプの攻撃は、強制切断です。サーバー認証から中間者保護、リプレイアタックに対する保護まで、すべてがTLSによって自動的に処理されます。これは、平均的な高レベルのプログラマーには見られないレイヤーでも行われます。あなたの状況では、残念ながら実際のTLS /（SSL）接続を利用できないことを指摘しています。ただし、TLSに代わるように設計されたカスタム実装は使用しないことを強くお勧めします。
エンドツーエンドのTLSほど良くないので、最後の手段となる可能性があります...しかし、少なくともTLSを有効にするために CloudFlare のようなものを前に置くことができますクライアントエンドポイント？
別のオプションは、ブラウザーのプラグインまたはTampermonkeyスクリプトを記述して（クロスプラットフォームの頭痛を軽減するため）、JSコードをブラウザーに事前配信することです。これは純粋に最後の手段の尺度として言及します。
明らかな欠点は、ユーザーがプラグインが既にインストールされているコンピューターを使用するか、新しいデバイスを使用するたびにプラグインを再度ダウンロードする必要があることです。また、モバイルデバイスを使用することも困難です。