4

著作権で保護されたデータを Amazon S3 バケットでホストし (サーバーが処理できるよりも広い帯域幅を利用できるようにするため)、これらの著作権で保護されたデータへのアクセスを多数の許可されたクライアントに提供したいと考えています。

私の問題は次のとおりです。

  • サーバー側でこれらのリソースの署名付きの期限切れの HTTPS URL を作成します
  • これらの URL は、HTTPS 接続を介してクライアントに送信されます
  • クライアントがこれらの URL を使用してコンテンツをダウンロードすると、URL は中間者に対して明確に表示されます。

詳細には、フォグ ジェムを使用して Ruby On Rails サーバー経由で URL が作成されます。私が話しているモバイル クライアントは iOS デバイスです。テストに使用したプロキシは mitmproxy です。

生成した URL は次のようになります。

https://mybucket.s3.amazonaws.com/myFileKey?AWSAccessKeyId=AAA&Signature=BBB&Expires=CCC

私はネットワークやセキュリティの専門家ではありませんが、HTTPS 接続では何も明らかになっていないというリソースを見つけました (たとえば、HTTPS ヘッダーは暗号化されていますか?を参照)。この明確な URL につながったのは、テストの構成ミスですか? ここで何がうまくいかなかったのかについてのヒントはありますか? S3 URL がネットワーク経由でクリアされるのを防ぐことができる可能性は本当にありますか?

4

1 に答える 1

4

まず、SSL 経由でリクエストを送信すると、すべてのパラメータが暗号化されます。通常のプロキシを通過するトラフィックを調べた場合、それらを読み取ることはできません。

ただし、多くのプロキシは、ダミーの証明書を作成することで SSL データの傍受を許可します。これはまさにmitmproxyが行うことです。これを有効にしたのに気付いていない可能性があります (ただし、これを行うにはクライアント側の証明書をインストールする必要がありました)。

肝心なのは、AWS URL は、プロキシを介して、またはバイナリ自体を利用して、アプリケーションをリバース エンジニアリングしようとする誰かによって簡単に傍受される可能性があるということです。ただし、これ自体は「悪いこと」ではありません。Amazon 自身はこれが発生することを認識しており、そのため、URL 自体で秘密鍵を直接送信するのではなく、署名を使用しています。

これはあなたにとって大きな問題ではないと思います: 結局のところ、あなたは期限切れの URL を作成しているので、誰かがプロキシ経由で URL を取得できたとしても、その URL にアクセスできるのは次の期間だけです。それは有効です。有効期限後にリソースにアクセスするには、秘密鍵に直接アクセスする必要があります。さて、これは実際には不可能ではないことがわかりました (バイナリにハードコーディングした可能性があるため) が、ほとんどのユーザーが気にしないほど難しいです。

セキュリティと著作権の防止について現実的になることをお勧めします。クライアント側のネイティブ コードを取得した場合、それが壊れるかどうかは問題ではなく、いつ.

于 2013-01-29T11:37:14.913 に答える