1

I am pretty new to ELB in AWS stack and have got a requirement where the two components running on two EC2 instance to communicate over TLS and there is a TLS level authentication by component 2 from any incoming session from component 1.

Basically my component 2 is going to open the cert of incoming request at SSL handshaking level, decide using EKU/OID that its coming from some reliable source and then allowing the handshake to succeed.

Now the two components need to go behind an ELB to ensure that its scalable. While going through a couple of resources for ELB, it came to my understanding that ELB terminates the TLS and then may be using an all together new certificate ELB can pass on the request to the instance behind the ELB.

First of all, is this understanding correct. Ideally I need that the TLS originally should pass on to the machine behind ELB so that my authentication logic does not break. Second if there is no way to do that can I do that authentication at ELB level, for that there is a need to do a DB lookup and possibly a small Java program that can open the cert, verify details and then either drop or pass on the message.

Not sure if my ask is even clear or not and for that please drop any comments, but any answer or pointers will be helpful.

-Anurag

aj1984
  • 111
  • 1

1 Answers1

2

You could try using an TCP/SSL load balancer. It works at the TCP layer (layer 4), as opposed to the application layer listening to http/https (layer 7). Proxy protocol may also help.

With both SSL and HTTPS load balancers I think the ELB terminates the TCP connection and starts up another connection from the ELB to the back end service. You could consider other load balancing solutions. ELB is managed HAProxy, you can run an EC2 instance with whatever load balancer you like, and put it in an auto scaling group with a size of one so if it fails it comes back up automatically.

Route 53 weighted resource sets might be another way to approach this. Basically clients are routed to servers based on weights you specify. You'd just create a bunch of records in the same set pointing at different EC2 instances. It's not really that scalable, and it's manual, so it's not a great solution either really.

The best option might be to scale vertically (ie get a bigger instance) and not bother with a load balancer. If all one server does it terminate TCP and authentication it should handle a lot of traffic. Alternately you could reconsider how you're doing authentication.

Update Based on what Michael said in the comment I did a bit more reading. I think he's most likely right, a TCP load balancer (not SSL) is most likely to be the passthrough connections without changing them, like a router.

My suggest to scale vertically is because you might find anything up to an m4.16XL might be enough, if it meets capacity and reliability requirements. It'd be easier to deploy a single server than a load balancer and multiple servers, and saves the cost of the ELB. It will likely be less reliable though.

Tim
  • 31,888
  • 7
  • 52
  • 78
  • Hi Tim, I was exploring the TCP based load balancer option and it seems it can allow the SSL connection stream to pass even over ELB. However i do not get the point of sclaing vertically when load balancing option is available, anyways i cant scale up indefinitely ryt? Also the Route 53 weighted options puts too much intelligence on the AWS administrator instead of load balancer. Won't the TCP/SSL based option suffice? I just want my HTTPS/MQTTS requests to pass through ELB without TLS being terminated on ELB. – aj1984 Feb 15 '17 at 10:10
  • @Tim is the right track, here, so I hate to post another answer, but what's needed is *just* a TCP listener, no SSL configured on the listener, and no SSL toward the instance, as far as ELB configuration. You want the balancer to blindly tunnel the payload between client and instance so the instance can negotiate TLS directly with the client. Then enable Proxy protocol so that the instance can discover the source address of the client, if the backend can support that. – Michael - sqlbot Feb 15 '17 at 10:16
  • I've updated my answer, based on what Michael said and a bit more reading. – Tim Feb 15 '17 at 18:37