web-dev-qa-db-ja.com

AWS S3によるSSLv3サポートの無効化

AWSから、基本的に「S3はSSLv3サポートを無効にしています。アクセスは15日後に遮断されます」というメールを受け取りました。次に、「現在SSLv3を指定するクライアントからのリクエストを受け入れている」（本番環境にある）私たちが持っているいくつかのバケットをリストしました。完全なメールがここにあり、他のAWSユーザーも受け取っているようです：

https://Gist.github.com/anonymous/4240c8af5208782c144c

私の質問は、このシナリオをどのようにテストするか、そしてこの締切日の準備のために何をする必要があるかです。

AWSアクセスにはRails 4.1 and the Fog（〜> 1.28.0）およびright_aws（〜> 3.1.0）gemを使用しており、Herokuを使用しています。このアプリでは、 UIでブラウザーユーザーにS3リソースを提供します。

これは単なるクライアント（ブラウザ）の問題ですか、それとも、理解を深め、テスト/修正する必要がありますか？

ruby-on-railssslherokuamazon-s3fog
31
user1690146

fogはhttp（s）トランスポートにexconを使用します。 exconは、低レベルの純粋なRuby httpクライアントであり、Ruby opensslバインディングが機能することに依存しています。使用するsslバージョンを明示的に設定することは可能ですが、exconはそうではありません。私の知る限り、使用するものを選択するためにサーバーとネゴシエートすることを意味するはずです（したがって、サーバーがSSLv3を要求しない場合は、連携する必要があります）。

ここでは何もする必要がないことを意味しますが、RubyとOpenSSLのバージョンによって少しずつ異なります）の詳細（内省/理解が少し難しいことは言うまでもありません）これらのバインディングの詳細）のため、特定のことを言うのは困難です。exconはssl_version引数をサポートします。これは、特定のバージョンが問題になる場合にそれを強制するために使用できます（これは、一般的に適切な選択ではありません。ネゴシエーションを許可せず、詳細はRubyバージョン）によって異なります。

お役に立てば幸いです。

9
geemus

締め切りは移動しました：

受け取ったフィードバックに基づいて、S3バケットへの接続を保護するためのSSLv3のサポートを終了する期限を2015年5月20日の午前12:00 PDTに延長します。

9
miloshes

2015年5月7日更新、11：26 AM IST

キャリアウェーブイニシャライザで、次のように置きます、

CarrierWave.configure do |config|
  config.fog_credentials = {
      :provider               => 'AWS',       # required
      :aws_access_key_id      => Settings.carrier_wave.Amazon_s3.access_key,       # required
      :aws_secret_access_key  => Settings.carrier_wave.Amazon_s3.secret_key,       # required
      :region                 => 'external-1'  # optional, defaults to 'us-east-1'
  }
  config.fog_directory  = Settings.carrier_wave.Amazon_s3.bucket                    # required
  #config.fog_Host       = 'http://aws.Amazon.com/s3/'            # optional, defaults to nil
  config.fog_public     = false                                   # optional, defaults to true
  config.fog_authenticated_url_expiration = 600
  config.fog_attributes = {ssl_version: :TLSv1_2} #{'Cache-Control'=>'max-age=315576000'}  # optional, defaults to {}
end

これは私にとってはうまくいき、wiresharkトレースログを確認します。

1577    22.611358000    192.168.0.113   8.8.8.8 DNS 87  Standard query 0xffd8  A s3-external-1.amazonaws.com
1578    22.611398000    192.168.0.113   8.8.8.8 DNS 87  Standard query 0xbf2f  AAAA s3-external-1.amazonaws.com
1580    22.731084000    8.8.8.8 192.168.0.113   DNS 103 Standard query response 0xffd8  A 54.231.1.234
1586    22.849595000    54.231.10.34    192.168.0.113   TLSv1.2 107 Encrypted Alert

1594    23.012866000    192.168.0.113   54.231.1.234    TLSv1.2 347 Client Hello
1607    23.310950000    192.168.0.113   54.231.1.234    TLSv1.2 204 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
1608    23.578966000    54.231.1.234    192.168.0.113   TLSv1.2 129 Change Cipher Spec, Encrypted Handshake Message
1609    23.579480000    192.168.0.113   54.231.1.234    TLSv1.2 427 Application Data
1610    23.868725000    54.231.1.234    192.168.0.113   TLSv1.2 299 Application Data

2015年5月6日更新、6-53 PM IST

OK、Excon gemを更新すると、TLSv1.2サーバーとS3サーバー間のプロトコル。

bundle update excon

Wiresharkトレースログステートメント、

29  1.989230000 192.168.0.115   54.231.32.0 SSL 336 Client Hello
34  2.215461000 54.231.32.0 192.168.0.115   TLSv1.2 1494    Server Hello
40  2.219301000 54.231.32.0 192.168.0.115   TLSv1.2 471 Certificate
42  2.222127000 192.168.0.115   54.231.32.0 TLSv1.2 204 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

2015年5月6日更新、4-29 PM IST

Hostsファイルを更新した後、wiresharkトレースログは次のようになります。

14  2.012094000 192.168.0.115   54.231.32.0 SSLv3   192 Client Hello 
17  2.242423000 54.231.32.0 192.168.0.115   SSLv3   61  Alert (Level:  Fatal, Description: Handshake Failure)

Wireshark request capture

上記のWiresharkリクエストのキャプチャを参照してください。ローカル開発からファイルをアップロードするときRails S3にあります。示されているように、最初のハンドシェイクでは、AmazonサーバーはSSLv3を使用するため、RailsサーバーはSSLv3ですべての将来のリクエストを送信します。

さて、問題は、TLSのみを使用してプロセスを受け入れる/開始するようにバケット設定を変更するにはどうすればよいですか？アマゾンの設定で確認しましたが、そのようなものはありません。

私はすでにnginxをTLSを使用するように変更しましたが、Railsは上記のコメントで述べたようにExconを使用してバックグラウンドでS3と通信するため、それは必要ないと思います。

そのため、5月20日までにこれをテストするための最良の方法を提案し、その日に壊れないことを確認してください。

どんな助けでも素晴らしいでしょう。

参考までに-私のバケット名はxyz.abc.comのようなものなので、名前には含まれません。

8
Parth

AWSの公式FAQ https://forums.aws.Amazon.com/thread.jspa?threadID=179904&tstart=

_54.231.32.0 s3.amazonaws.com
54.231.32.1 <bucket name>.s3.amazonaws.com
54.231.32.3 <bucket name>.s3-external-1.amazonaws.com
_

_/etc/hosts_を上記のように構成し、_<bucket name>_をバケット名に置き換えます。

注：_us-east-1_以外のバケットで使用すると、リダイレクトと失敗の応答が返される場合があります。これは、何よりも、これをテストするためのアドホックインフラストラクチャに関係しています。無視してください。

「標準のUSバケット」を作成し、代わりにそれでテストします。 s3リージョンを使用するようにアプリを構成することを忘れないでください_external-1_

FWIW、_Ruby 2.1.4_でPaperclip (4.2.0)を使用する私のアプリは正常に動作します。

6
choonkeat

これは完全にクライアント側の問題であり、クライアント（ブラウザなど）がhttps経由でリクエストを発行するために使用するプロトコルがSSLv3の場合、sslハンドシェイクは成功せず、これらのリクエストは失敗します。つまり、SSLv3を無効にする必要があるのはクライアントです。

AWSのアクションは、昨年発見されたPOODLE脆弱性のフォローアップであり、それ以降、*。cloudfront.netドメイン名を使用するすべてのAWS CloudFrontディストリビューションも廃止されたSSLv3サポートで更新されました。現在、AWSはS3に移行しています。同じことをする。

4
Simona Miroiu

私のフォグ設定で次の設定を使用してTLSを強制することができました：

connection_options：{ssl_version：：TLSv1_2}

テストするには、Hostファイルを更新します（AWSからの指示）。

54.231.32.0 s3.amazonaws.com
54.231.32.1 bucket.s3.amazonaws.com   #replace bucket with your bucket name
54.231.32.3 bucket.s3-external-1.amazonaws.com   #replace bucket with your bucket name

うまく接続できました。また、設定を：SSLv3に変更すると、エラーが発生します。幸運を！

2
Chris