AWS Cloudfront 级别的 SSL 卸载答案

【问题标题】：SSL offloading on AWS Cloudfront levelAWS Cloudfront 级别的 SSL 卸载
【发布时间】：2017-04-17 04:27:05
【问题描述】：

我们使用以下 AWS 基础设施：

Route53-> CloundFront -> Elasticbeanstalk(+LoadBalancer=ELB) -> EC2 实例

现在我们在 CloudFront 级别设置了 ssl 证书，在 ELB 级别设置了相同的证书，从而为我们提供了 CF 和 ELB 之间的端到端加密。 AWS CF 和源之间的 End2End 被描述为最佳实践 here。

这是指picture 上的完整 SSL（严格）（这是用于 CloudFlare 堆栈，但它是为了更好地说明，所以没关系）。我们希望在 AWS CF 级别卸载 SSL，以避免从 CF 到 ELB 的往返移动到灵活 SSL，如图所示。

在 CF 级别卸载 SSL 是个好主意吗？在 CF 级别之后是否有任何值得放弃端到端加密的性能改进？

我们能否以某种方式限制 ELB 只接受来自某些 AWS CF 的连接？

此外，还有一些关于 ELB SSL performance 的性能问题（似乎被证明很擅长，但我仍然有顾虑）。一般来说，如果 AWS CF 在 SSL 解密工作上的表现优于 ELB，这也很有趣。

【问题讨论】：

【解决方案1】：

根据您的应用程序的性质和合规性要求，是否在 CF 上卸载 SSL。

通常，如果所有实体都通过 CF 访问应用程序（例如，没有从某些客户端到后端 VPC 的 VPN 连接），在 CF 处卸载就足够了。两者都使用 SSL 的性能差异并不显着。

仅允许从 CF 到 ELB 的入站，目前没有可用的直接方法。一种可能的方法是使用 Lambda 函数更新 ELB 的安全组，从 AWS 提供的 JSON url 获取 CF IP 范围。

与 ELB 相比，CF 的 SSL 卸载速度也更快，因为有许多在边缘位置运行的服务器接受您的连接，而 ELB 为每个 AZ 都有服务器（通常是 2 或 3 个）。

【讨论】：

“一种可能的方法是使用 Lambda 函数更新 ELB 的安全组，从 AWS 提供的 JSON url 获取 CF IP 范围。” 这并不是特别有用，因为它仍然允许任何 CloudFront 分配（包括由其他人创建的分配）联系您的 ELB。
当安全组被列入 CF IP 范围的白名单时，其他 CF 确实也可以访问，但它减少了攻击面，因为 CF 只允许第 7 层流量。但是，如果您想将其限制为单个 CF，您可以将安全组与 CF 生成的标头结合使用，该标头已在您的服务器上验证
在 CloudFront 后面部署 SSL 对 ELB 的影响应该最小的另一个原因是 CloudFront 将保留并重用自身与 ELB 之间的连接，从而最大限度地减少设置这些连接的开销，即SSL 中耗时且昂贵的部分。