问题
在我的Rails应用程序中,我一直看到赫鲁库·雷迪斯 Premium0插件的错误:
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error:证书验证失败(证书链中的自签名证书)
Heroku 文档提到,为了连接到Redis 6数据库,我需要在Redis客户端的配置中启用TLS。为此,我阅读了redis-rb上的SSL/TLS支持文档。我的理解是:我需要为ca_file、cert和key分配Redis.new#ssl_params。问题是如何将这些设置为Redis或通过Sidekiq对Heroku?
更新
更新3: Heroku支持提供了解决问题的答案。
更新2:创建Heroku支持票和等待响应。
更新1:问对Sidekiq的Github问题和建议,去写Heroku支持。当我得到答案的时候,会更新这个问题。
相关信息
我已经验证了应用程序的工作,当外接程序是以下之一:
版本:
一些链接帮助我缩小了问题的范围:
发布于 2021-01-22 13:08:02
解决方案
对您的Redis客户端使用OpenSSL::SSL::VERIFY_NONE。
塞迪基克
# config/initializers/sidekiq.rb
Sidekiq.configure_server do |config|
config.redis = { ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE } }
end
Sidekiq.configure_client do |config|
config.redis = { ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE } }
endRedis
Redis.new(url: 'url', driver: :ruby, ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE })原因
Redis 6需要TLS连接。然而,Heroku支持解释说,他们管理从路由器级别到应用程序级别的涉及自签名Certs的请求。结果表明,Heroku在路由器级别终止SSL,请求通过HTTP从那里转发到应用程序,而所有东西都在Heroku的防火墙和安全措施之后。
源
发布于 2021-07-05 11:58:45
如果使用ActionCable,还可能需要将verify_mode添加到`cable.yml配置中:
production:
adapter: redis
url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>
channel_prefix: my_app_production
ssl_params:
verify_mode: <%= OpenSSL::SSL::VERIFY_NONE %>发布于 2021-07-30 16:45:58
如果您使用的是Rails 5,则通过将无法配置文件将Redis的ssl_params用于ActionCable。相反,您可以在初始化器中手动设置redis_connector属性,如下所示:
# frozen_string_literal: true
require "action_cable/subscription_adapter/redis"
ActionCable::SubscriptionAdapter::Redis.redis_connector = ->(_config) do
Redis.new(...your options here...)
end要了解更多关于使用OpenSSL::SSL::VERIFY_NONE的含义以及如果您在Heroku上可能还可以的原因,请参阅以下内容:
使用OpenSSL::SSL::VERIFY_NONE告诉客户端使用自签名证书是可以的,不会尝试验证证书是否由已知的证书颁发机构签名。
有可能发生中间人攻击。如果试图与Heroku Redis交谈的客户端没有验证它遇到的SSL证书是否属于Heroku (AKA,这些证书由一个证书颁发机构签名,该证书验证了请求证书的实体实际上是Heroku),那么坐在您的客户端和Heroku Redis之间的攻击者就可以创建自己的自签名SSL证书并假装是Heroku。这意味着他们可能会拦截你试图发送给Heroku Redis的任何流量。
在实践中,这可能不是一个与Heroku交谈的Heroku的现实场景。
以下是Heroku support的引语:
MITM攻击对托管主机提供商来说是不切实际的。对于一个糟糕的演员来说,在AWS上托管的dyno和Redis实例之间是很困难的。这是因为位于同一AZ中的EC2实例在任何时候都不应该在AWS基础设施之外路由。在这种情况下,MITM攻击只能由托管服务提供商设施本身内的坏参与者执行,因为网络流量从未离开所述设施。
以下是AWS文档中的一些片段,它们似乎证实了这一点:
https://aws.amazon.com/vpc/faqs/
当两个实例使用公共IP地址进行通信时,还是当实例与公共AWS服务端点通信时,流量是否在互联网上传输? 不是的。当使用公共地址空间时,AWS中承载的实例和服务之间的所有通信都使用AWS的专用网络。来自AWS网络和AWS网络上的目的地的数据包停留在AWS全局网络上,但与AWS中国区域的通信量除外。 此外,通过AWS全球网络互连我们的数据中心和区域的所有数据在离开我们的安全设施之前都会在物理层被自动加密。还存在其他加密层;例如,所有VPC跨区域对等通信以及客户或服务传输层安全性(TLS)连接。
和https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html
Amazon虚拟私有云(,Amazon)使您能够在AWS云中您自己的逻辑隔离区域中定义一个虚拟网络,称为虚拟私有云(VPC)。 当您创建AWS帐户时,我们将在每个区域为您创建默认的VPC。
https://stackoverflow.com/questions/65834575
复制相似问题