Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Support for two-way TLS/HTTPS with ELB

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

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

Assuming ELB is terminating a TLS/HTTPS connection:

  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 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.

like image 689
pd40 Avatar asked Jan 20 '14 22:01

pd40


People also ask

Does AWS ELB support mutual TLS?

AWS load balancers do not support mutual TLS. There is no way to make that work on the load balancer itself. So if you want to support mutual TLS in your application, the only option you have is to configure the load balancer in TCP passthrough, and handle mutual TLS yourself.

Does AWS ALB support 2 way SSL?

No this is not supported.

Does ALB support TLS?

ALB will automatically choose the optimal TLS certificate for each client. These new features are provided at no additional charge. If you're looking for a TL;DR on how to use this new feature just click here.

Does application load balancer support TLS?

TLS OffloadingApplication Load Balancer supports client TLS session termination. This enables you to offload TLS termination tasks to the load balancer, while preserving the source IP address for your back-end applications.


2 Answers

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.

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.


Update:

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.”

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.

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.

like image 181
Michael - sqlbot Avatar answered Sep 18 '22 08:09

Michael - sqlbot


In case your back end can support client authenticated HTTPS connections itself, you may use ELB as TCP on port 443 to TCP on port your back end listens to. This will make ELB just to resend unencrypted request directly to your back end. This config also doesn't require installation of SSL certificate to a load balancer.

Update: with this solution x-forwarded-* headers are not set.

like image 39
scrutari Avatar answered Sep 18 '22 08:09

scrutari