web-dev-qa-db-ja.com

POST HTTPS経由で機密データに対して「十分に安全」ですか?

SSLを介して渡されるデータをさらに暗号化することが賢明である場合、SSL証明書のセキュリティが侵害されて機密情報が漏洩する可能性を防ぐことができるかどうか疑問に思っています。

架空のシナリオ:2つのWebアプリケーション。 1つはWebアプリケーションで、もう1つは認証APIを提供するアプリケーションです。

Webアプリは、HTTPS POSTをユーザー名とパスワードを含む認証APIに送信します。SSLを介して暗号化されます。

しかし、攻撃者がSSL証明書を危険にさらした場合、そのデータを盗聴することはできませんか?

私の考えは、別のレベルの暗号化を追加することです-たとえば追加の公開鍵と秘密鍵のペアがあり、POSTのすべての情報もそれによって暗号化します。

つまり、SSL証明書を侵害した攻撃者は、通信を遮断するために追加の秘密鍵を見つける必要があります。

考え?

10
user8405

余分な暗号化の代わりに、必須が安全である場合は、2要素認証を使用します。ユーザーにユーザー名、パスワード、および電子メールまたはSMSで送信された6桁の乱数を入力させます。侵害された証明書は、攻撃者がSSLペイロード全体を双方向で制御できる可能性があることを意味します。サーバーでの認証に必要な暗号化を実行するためにクライアントに送信するコードを含みます。

また、アプリケーションサーバーと認証サーバーを分離することも検討してください。これにより、ユーザーが実際にアプリケーションサーバーで受け入れられない場合、取得したユーザー名とパスワードのリストを使用して攻撃者が有用なことを行うのは非常に困難になります。これはOAuth2の背後にある概念です。 1つのサーバーを回復する方が、2つのサーバーを攻撃するよりもはるかに簡単です(少なくとも理論上は)。

6
phyrfox

私は、「ウェブアプリ」がPOSTを送信すると言っていると想定していますが、本当の意味は、ユーザーのブラウザーのHTMLウェブページがPOSTサードパーティのサーバーへのリクエスト

外部の攻撃者(不正なCA /政府)によるSSL/TLSの侵害のイベントは、おそらく非常に低いものです。これには2つの可能性があります。

#1。無関係な攻撃によりサーバーが侵害され、秘密鍵が盗まれた

システムに誰かがいて、秘密鍵にアクセスできる場合、それらはおそらくアプリケーション/ソースにアクセスし、データ(MITM)を吸い上げるように変更できます。その時点では、追加の暗号化はあなたを救うことはありません。

#2。 SSL/TLSの作成/展開に使用される設定が不適切です。安全でないアルゴリズム/ハッシュまたは古いSSLバージョンを使用している場合、SSL固有の攻撃に対して脆弱になる可能性があります( http://en.wikipedia.org/wiki/Transport_Layer_Security#Security )。 SSL 3/TLSを使用することを忘れないでください。できればTLS 1.2。

2
Daisetsu

はい! TLSはnot安全です-証明書の置換はextremely共通です(ほとんどの企業はコンテンツ検査Edgeデバイス、ほとんどの学校とunis、すべての優れたファイアウォール、さらにはいくつかのすべてのユーザーが自分のCAをインストールするように強制し、MitMを実行して「暗号化された」トラフィックを検査できるようにします)。約2か月ごとに、新しいCAも侵害されたことが判明しています。被害者のマシンに独自のCAをインストールするマルウェアもたくさんあります。

2FAの使用は、この問題の解決策ではありません。 2FAは35年の歴史を持つ認証技術であり、トラフィックの傍受に対する保護とは何の関係もありません。

0
Anon Coward

秘密鍵が危険にさらされていると想定している場合(証明書はトランザクションごとに提供されますが、秘密鍵がないと役に立たない)、銀行にいたはずです。この場合、銀行によって提供されるその他のセキュリティメカニズムも同様に無効です。

ブラウザーまたはアプリケーションに追加のCA権限があると想定している場合(雇用主がよく行うように)、基本的にクライアントが危険にさらされます。 CAのリストを信頼しない場合、ブラウザにフックがないこと、またはキーロガーが信頼できないのはなぜですか?

これを作成しているアプリケーションから行う場合は、接続用のTLS証明書を取得できるはずです。これは、ブラウザでJava=の場合)可能です(ただし、JavaScriptからではないようです)。もちろん、アプリケーション/ Javaプログラムが改ざんされていないことを前提としています。信頼できないプラットフォームで信頼できるコードを実行する方法はありません。

Diffie-Hellmanを使用したTLS接続を使用している場合、秘密鍵を使用しても、キャプチャされたデータを復号化することはできません(引用: https://support.citrix.com/article/CTX116557 )。

中間者攻撃は、Diffie-Hellmanでも機能します(攻撃者が秘密キーと証明書を持っている場合、それらは正当な所有者と区別できません)。

私の個人的な意見では、誰かが私のデータを改ざん/改ざんしようとしている場合、暗号化の別のレイヤーは必要ありません。

注:マルウェア対策ソフトウェアによって追加のCA証明書がインストールされているのを確認したので、httpsによって配信されたマルウェアをスキャンできます。

0
AMADANON Inc.