AWS S3禁用SSLv3支持

Question

我们收到来自AWS的电子邮件,其中基本上说"S3正在禁用SSLv3支持,访问将在15天内被截止".然后他们列出了我们拥有的一些存储桶(一个正在生产中),这些存储桶"正在接受来自指定SSLv3的客户端的请求".完整的电子邮件在这里,其他AWS用户似乎也收到了一封:

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

我的问题是我们如何测试这种情况,以及我们需要做些什么才能为这个截止日期做准备？

我们使用Rails 4.1和Fog(〜> 1.28.0)和right_aws(〜> 3.1.0)宝石进行AWS访问,我们使用的是Heroku.我们的应用程序在我们的UI中为我们的浏览器用户提供了S3资源的签名HTTPS链接

这只是客户端(浏览器)问题还是我们需要更好地理解和测试/修复的问题？

Answer 1

fog使用excon进行http(s)传输.excon是一个低级的纯ruby http客户端,它依赖于ruby openssl绑定来工作.虽然可以明确设置一个ssl版本来使用,但excon没有,据我所知,这应该意味着它与服务器协商选择使用什么(所以如果服务器要求不是SSLv3,它应该合作).

我认为这应该意味着这里不需要采取任何行动,但是Ruby和OpenSSL版本之间的所有细节都有所不同(更不用说内省/了解这些绑定的具体细节有点难度),所以它很难肯定.excon确实支持一个ssl_version参数,如果它最终成为一个问题,它可用于强制特定版本(这不是一个很好的一般选择,因为它不允许协商,并且细节在ruby版本之间有所不同).

希望有所帮助.

Answer 2

截止日期已被移动:

根据收到的反馈,我们将延长停止支持SSLv3的截止日期,以确保到S3存储桶的连接到2015年5月20日凌晨12:00.

Answer 3

更新2015年5月7日,上午11:26 IST

在carrierwave初始化程序中,放置如下内容,

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点IST

好的,在更新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点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)

当我从S3上的本地开发轨道上传文件时,请查看上面的wireshark请求捕获.如图所示,在初始握手时,亚马逊服务器使用SSLv3,因此我的rails服务器使用SSLv3发送所有未来的请求.

现在,问题是,如何更改存储区设置,以便它仅使用TLS接受/启动进程？我已经检查了亚马逊设置,没有类似的东西.

我已经更改了我的nginx以使用TLS,但我认为这不是必需的,因为Rails将在后台使用Excon与S3对话,如上面评论中所述.

因此,请建议在5月20日之前测试此功能的最佳方法,以确保它不会在当天中断.

任何帮助都会很棒.

仅供参考 - 我的桶名称类似于xyz.abc.com,所以没有 - 在名称中.

Answer 4

AWS的官方常见问题解答https://forums.aws.amazon.com/thread.jspa?threadID=179904&tstart=0

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存储桶时,您可能会遇到重定向和故障响应.这与他们的特殊基础设施有关,而不是其他任何东西.所以忽略它.

创建一个"标准美国桶",然后用它进行测试.请记住将您的应用配置为使用s3区域external-1

FWIW,用我的应用程序paperclip (4.2.0)上ruby 2.1.4正常工作.

Answer 5

这完全是一个客户端问题，如果客户端（例如浏览器）用于通过 https 发出请求的协议是 SSLv3，那么 ssl 握手将不会成功并且这些请求将失败。因此，需要禁用 SSLv3 的是客户端。

AWS 的行动是对去年发现的 POODLE 漏洞的后续行动，从那时起，所有使用 *.cloudfront.net 域名的 AWS CloudFront 发行版都已更新为停止支持 SSLv3。现在 AWS 正在转向 S3照着做。