web-dev-qa-db-ja.com

REST API-SSL内の実際のデータを暗号化するためにPGPまたはAESを使用した人はいますか？

おそらく私は過度に偏執狂的ですが、ネットワークセキュリティに関する最近のニュースを読んだ後、SSLは機密データの送信にはもう十分ではないと信じ始めています。

参照：

私は、主に私的使用（会社のマシンが互いに対話する）のために、いくつかの新しいAPIの構築を検討しているWeb開発者です。一部のシステムは、企業ネットワークの外部にある可能性があります。私の質問は、API自体に関連する追加のセキュリティについてです。

実際に暗号化するためにPGPやAESのようなものを考えたり実装したりしたことがある人はいますかすべてのデータ API通信内を行き来していますか？

私は外側のブランケットラッパーとして引き続きSSLを使用していることについて話していますが、その後、ペイロード全体を暗号化することでさらに一歩進んでいます。明らかに、これは両端での暗号化/復号化でいくつかの急なオーバーヘッドを作成します。事は、私はこれで概念的に大丈夫です。ハードウェアが安い。

特に好きではないのは、データをクリアテキストで送信し、すべての卵をSSLバスケットに入れることだけです。

考え？

tlsappsecrest
16
Steve

はい、暗号化の層が理にかなっている状況があります。これが1つの具体的な例です。

SSLは、途中でによって正当に復号化される可能性があります。常にエンドツーエンドではありません。

  • アカマイは、コンテンツ配信を提供しているトラフィックを復号化および再暗号化する場合があります。
  • Prolexicは、DDoSから保護するように要求されたときに、パケットを開いて、何を許可し、何をドロップするかについてスマートな決定を下せるように、クライアントのSSLキーを必要としています。
  • 分析のためにトラフィックを復号化するためにIDS/IPSに秘密鍵が設定されている可能性があり、機密データがそこに記録されないように保護したい場合。
  • SSLはビジネスの内部であっても、パフォーマンス上の理由でSSL Edgeゲートウェイで復号化され、内部ネットワークでは暗号化されずに渡される場合があります。

誰かがここにジャンプして、「SSLをそのように使用すべきではありません！」と言うでしょう。同意した。現実の世界では、合理的な理由から、たまたま時間はたまたま発生します。

私の会社には、あなたが説明したことを行うAPIがあります。 XML-over-HTTPSトランザクションには、公開鍵暗号化で暗号化された特定の機密フィールドがあります。 SSLは、機密情報を公開せずに、上記のような理由で暫定ホストによって復号化できます。これは、実際の問題に対するスマートなソリューションです。

16
gowenfawr

同僚と私は、数年前にAppSec USAでこのトピックについてプレゼンテーションを行いました。 （最初は少し乾燥していることを認めますが、途中でもっと面白くなります:)

http://www.youtube.com/watch?v=4s0rZgcATrg

答えは、脅威モデルが何であるかによって異なります。

脅威モデルに悪意のあるエンドユーザーが含まれている場合、SSLは十分ではありません。エンドユーザーは自分のマシンを簡単にMITMして、APIトラフィックを表示または変更できます。私たちの話では、架空のシナリオを示します

脅威モデルに中間者攻撃を実行する国家が含まれている場合、サードパーティCAを使用したSSLも安全ではありません。 （これは、Rookが上で参照しているものです。）証明書のピン留めは可能な回避策です（話の中でそれについて説明します）が、証明書が期限切れになったときにロールオーバーするのが非常に難しいなど、いくつかの欠点があります。

私たちの話はいくつかの可能な緩和策を扱っていますが、あなたの制御下にないデバイスを信頼するという根本的な問題は一般に解決されていません。

7
Mark E. Haase

データを暗号化し、SSL/TLSストリームを使用してこの暗号文を送信すると、セキュリティ上の利点がゼロになり、リソースの浪費にすぎません。 SSL/TLSは機密性だけでなく、SSL/TLSを使用して暗号文を送信することは冗長です。 MITM攻撃（BGPまたはDNS）およびその他の形式の政府による強制を防ぐことが証明されているのは、Certificate Pinningです。読む： アプリケーションはSSLの問題に悩まされるべきではありません 。 証明書のピン留めにHTTP-Strict-Transport Security（HSTS）を使用 がHTTPSを改善するための便利なツールになるので、楽しみにしています。

SSL/TLSは非常に効率的で設計がしっかりしており、一方でPKIは永続的に壊れており、誰からも信頼されるべきではありません。壊れたPKIが脅威モデルに影響を与える場合は、証明書の固定を使用します。特定のアルゴリズムを使用したくない場合は、許可された暗号スイートの独自のリストを定義します。

4
rook