支持带 ELB 的双向 TLS/HTTPS [英] Support for two-way TLS/HTTPS with ELB

问题描述

使用 Amazon Elastic Load Balancing 的一种方式(或服务器端)TLS/HTTPS 是 有据可查

One way (or server side) TLS/HTTPS with Amazon Elastic Load Balancing is well documented

文档中没有明确支持双向(或客户端)TLS/HTTPS.

Support for two-way (or client side) TLS/HTTPS is not as clear from the documentation.

假设 ELB 正在终止 TLS/HTTPS 连接:

Assuming ELB is terminating a TLS/HTTPS connection:

1. ELB 是否支持客户端身份验证 HTTPS 连接?
2. 如果是，ELB 服务的服务器是否收到 X-Forwarded-* 标头来标识通过ELB 认证的客户端?

1. Does ELB support client authenticated HTTPS connections?
2. If so, does a server served by ELB recieve a X-Forwarded-* header to identify the client authenticated by ELB?

ELB 确实支持 TCP 转发，因此 EC2 托管服务器可以建立双向 TLS/HTTPS 连接，但在这种情况下，我对 ELB 终止 TLS/HTTPS 连接并识别客户端感兴趣.

ELB does support TCP forwarding so an EC2 hosted server can establish a two-way TLS/HTTPS connection but in this case I am interested in ELB terminating the TLS/HTTPS connection and identifying the client.

推荐答案

我不明白在双端 HTTPS 模式下怎么可能，因为 ELB 正在建立到后端服务器的第二个 TCP 连接，并且在内部，它正在解密/加密来自客户端和服务器的有效负载......因此服务器不会直接看到客户端证书，并且除了 -For、-Proto 和 - 之外没有记录的 X-Forwarded-* 标头端口.

I don't see how it could, in double-ended HTTPS mode, because the ELB is establishing a second TCP connection to the back-end server, and internally it's decrypting/encrypting the payload to/from the client and server... so the server wouldn't see the client certificate directly, and there are no documented X-Forwarded-* headers other than -For, -Proto, and -Port.

另一方面，ELB 在 TCP 模式下运行，SSL 协商直接在客户端和服务器之间完成，ELB 盲目地将流捆绑在一起.如果服务器支持PROXY协议，您可以在 ELB 中启用该功能，以便您可以识别客户端的原始 IP和服务器上的端口，以及直接识别客户端证书，因为客户端将直接与您协商......尽管这意味着您不再将 SSL 卸载到 ELB，这可能是您的一部分尝试做.

With an ELB running in TCP mode, on the other hand, the SSL negotiation is done directly between the client and server with ELB blindly tying the streams together. If the server supports the PROXY protocol, you could enable that functionality in the ELB so that you could identify the client's originating IP and port at the server, as well as identifying the client certificate directly because the client would be negotiating directly with you... though this means you are no longer offloading SSL to the ELB, which may be part of the point of what you are trying to do.

更新:

似乎没有一种方法可以完成您想做的所有事情——卸载 SSL 并识别客户端证书——仅使用 ELB.以下信息显示为其价值".

It doesn't look like there's a way to do everything you want to do -- offload SSL and identify the client certificatite -- with ELB alone. The information below is presented “for what it’s worth.”

显然HAProxy有支持1.5版的客户端证书，并在X- 标题.由于 HAProxy 还通过配置支持 PROXY 协议(类似于 tcp-request connection expect-proxy) ...所以可以想象您可以在 TCP 模式 ELB 后面使用 HAProxy，而 HAProxy 会终止 SSL 连接并将来自ELB的客户端IP/端口信息(通过PROXY协议)和客户端证书信息转发到应用服务器......从而使您仍然可以保持 SSL 卸载.

Apparently HAProxy has support for client-side certificates in version 1.5, and passes the certificate information in X- headers. Since HAProxy also supports the PROXY protocol via configuration (something along the lines of tcp-request connection expect-proxy) ... so it seems conceivable that you could use HAProxy behind a TCP-mode ELB, with HAProxy terminating the SSL connection and forwarding both the client IP/port information from ELB (via the PROXY protocol) and the client cert information to the application server... thus allowing you to still maintain SSL offload.

我提到这一点是因为它似乎是一个互补的解决方案，可能比单独的任何一个平台功能更完整，而且，至少在 1.4 中，这两个产品完美地协同工作——我在 ELB 后面成功地使用了 HAProxy 1.4 为所有人服务我最大的 Web 平台中的请求(在我的例子中，ELB 正在卸载 SSL——没有客户端证书)，尽管级联负载平衡器明显冗余，但它似乎是一个可靠的组合.我喜欢让 ELB 成为糟糕的互联网上唯一存在的东西，尽管我没有理由认为直接暴露的 HAProxy 本身会有问题.在我的应用程序中，ELB 用于在 A/Z 中的 HAProxies 之间进行平衡(我最初打算也自动缩放，但即使在我们的繁忙季节，CPU 利用率仍然很低，以至于我每个可用区，我从来没有丢失过一个，但是...)然后它可以在将流量传送到实际平台之前做一些过滤、转发和处理标头，除了给我一些日志记录、重写和流量分割控制，我在 ELB 上没有.

I mention this because it seems to be a complementary solution, perhaps more feature-complete than either platform alone, and, at least in 1.4, the two products work flawlessly together -- I am using HAProxy 1.4 behind ELB successfully for all requests in my largest web platform (in my case, ELB is offloading the SSL -- there aren't client certs) and it seems to be a solid combination in spite of the apparent redundancy of cascaded load balancers. I like having ELB being the only thing out there on the big bad Internet, though I have no reason to think that directly-exposed HAProxy would be problematic on its own. In my application, the ELBs are there to balance between the HAProxies in the A/Z's (which I had originally intended to also auto-scale, but the CPU utilization stayed so low even during our busy season that I never had more than one per Availability Zone, and I've never lost one, yet...) which can then do some filtering, forwarding, and and munging of headers before delivering the traffic to the actual platform in addition to giving me some logging, rewriting, and traffic-splitting control that I don't have with ELB on its own.

这篇关于支持带 ELB 的双向 TLS/HTTPS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！