ホストにいくつかの問題があるため、サーバーでSSL証明書を使用できず（プロバイダーを変更する準備ができていません）、HTTPSを使用できません。このサーバーは、いくつかのクライアントコンピューターと通信し、やや秘密のデータを転送します。
HTTPSの代わりにAES暗号化（送信前のクライアントでの暗号化、処理前のサーバーでの復号化）を使用するのは合理的でしょうか？
質問する
435 次
2 に答える
5
これは、展開環境によって異なります。
SSL / TLS（およびHTTPS）を独自の暗号化プロトコルに置き換えてWebブラウザーで使用することは、安全でない状態で配信されるJavaScriptコードに依存しているため（詳細については、たとえばSecurity.SEのこの質問を参照してください）、常に悪い考えです。
クライアントがWebブラウザでない場合は、さらに多くのオプションを利用できます。特に、トランスポートレベルのセキュリティ（HTTPSが使用するもの）の代わりにメッセージレベルのセキュリティを実装できます。
HTTPを使用してメッセージレベルのセキュリティを標準化する試みは数多くあります。例えば：
HTTPsecには公開仕様（WebArchiveで引き続き利用可能）がありましたが、商用実装です。これが広くレビューされているかどうかはわかりません。
WS-Security、SOAPの世界を対象としています。
おそらくもっと簡単に言えば、既存のツールを再利用したい場合は、S / MIMEまたはPGP（電子メールの場合と同じ方法）を使用してHTTPメッセージエンティティを暗号化できます。HTTPSとは異なり、これはURLまたはHTTPヘッダーを保護しませんが、機密データをそこに配置しない場合はこれで十分な場合があります。
自分で「生の暗号化」を使用するほど（たとえば、AESを直接使用する）、セキュリティの他の側面を手動で実装する必要があります（通常、リモートパーティのIDを確認し、事前の問題に対処します）。キーの共有）。
于 2012-11-26T16:43:40.267 に答える
0
頻繁に変更されないクライアントのリストが少ない場合は、SSHを使用して独自のSSLトンネルを実装できます。クライアントで行う;
ssh -D 4444 nulluser@example.com -N
nulluserにシェルまたはファイルアクセスがありませんexample.com。
次に、foxyproxyホワイトリスト設定を追加します。これによりexample.com、クライアントブラウザでlocalhost:4040プロキシが使用されます。
これはハックであり、完全にスケーラブルではありませんが、少数の静的なクライアントに対しては機能します。また、完全に安全でありながら、ホイールを再発明しないという利点があります。
于 2012-11-26T16:43:49.473 に答える