Our application needs end-end SSL encryption and here is the architecture:
Browser(https)-> AWS CloudFront(Https)- ON-perm F5 Loadbalancer(HTTPS)-> webserver.
AWS CloudFront with Origin pointing to On-Perm Load balancer(F5).
On-Perm Load balancer configured to do a sticky session with SSL-session-id(not application session-id)
Since AWS CloudFront domain name is mapped to dynamic IP and do SSL shake based on edge location IP SSL-sessionId changes even though the request is from the same application session-id it is causing session data loss for the user.
It's not an option for us to change the Load balancer to do session affinity based on application session-id nor we can do SSL termination at Loadbalancer. can someone please help me how can I do the session affinity in this scenario?
What you are attempting cannot be accomplished with Amazon CloudFront.
CloudFront is designed for performance, which means a single viewer connection can use multiple back-end connections in parallel and multiple viewers can also make sequential requests over a single back-end connection.
TLS through CloudFront is not end-to-end -- that would be impossible. CloudFront needs to decrypt and re-encrypt the traffic since it operates at the HTTP layer.
Related
I heard that to alleviate the web server of the burden of performing the SSL Termination, it is moved to load balancers and then HTTP connection is made from the LB to the web server. However, in order to ensure security, an accepted practice is to re encrypt the data on the LB and then transmit it to the web server. If we are eventually sending the encrypted data to the web servers, what is the purpose of having a LB terminate SSL in the first place ?
A load balancer will spread the load over multiple backend servers so that each backend server takes only a part of the load. This balancing of the load can be done in a variety of ways, also depending on the requirements of the web application:
If the application is fully stateless (like only serving static content) each TCP connection can be send to an arbitrary server. In this case no SSL inspection would be needed since the decision does not depend on the content of the traffic.
If the application is instead stateful the decision which backend to use might be done based on the session cookie, so that requests end up at the same server as the previous requests for the session. Since the session cookie is part of the encrypted content SSL inspection is needed. Note that in this case often a simpler approach can be used, like basing the decision on the clients source IP address and thus avoiding the costly SSL inspection.
Sometimes load balancers also do more than just balance the load. They might incorporate security features, like a Web Application Firewall, they might sanitize the traffic or similar. These features work on the content so SSL inspection is needed.
Last week I was playing with a load balancer for my TLS-enabled endpoints (share the same certificate) and was surprised it is possible to have TPC load balancer in place in front of SSL endpoint. Having that configured it was possible to communicate with TCP load balancer as like it configured to support TLS/SSL. So, I would like to ensure such a network configuration is fully working solution:
TLS/SSL session and handshake workflow are stateless, meaning it is possible to start handshake with a primary server and end it with a mirror. Is it true?
Are there any hidden dangers I must be aware of?
If previous statements are true, what the reason to to do all TLS/SSL work on a load balancer itself?
P.s. the reason I do not do TLS/SSL work on a load balancer is that I need to balance multiple proprietary endpoint only supports SSL/TLS.
TLS/SSL session and handshake workflow are stateless, meaning it is possible to start handshake with a primary server and end it with a mirror. Is it true?
No. I suspect your load balancer is using TCP keep-alive so that the handshake is completing on the same server every time.
Are there any hidden dangers I must be aware of?
You may be incurring a significant performance penalty. HTTPS has "session keys" that are, probably by default, unique to the server. If you aren't able to do something like sticky sessions with the load balancer, then you will do a full handshake every time a client moves from one server to the other.
You also will have session tickets that won't work between servers, so session resumption will probably not work either, and fall back to a full handshake. Some servers support configuring a common session ticket key, like nginx.
If previous statements are true, what the reason to to do all TLS/SSL work on a load balancer itself?
Well, they aren't entirely true. There are other benefits though. The main one being that the load balancer can be more intelligent since it can see the plaintext of the session. An example might be examining the request's cookies to determine which server to send the request to. This is a common need for blue/green deployments.
Here's my AWS architecture
1 Load Balancer
2 Web/Application server
1 DB server
If client - and my LB communicates with SSL(HTTPS) protocol,
would it be safe with internal LB-WEB/APP-DB server communicates with HTTP? Or should they communicate with same SSL certificates internally too?
You certainly can terminate SSL on your web instances, but it is probably much easier to have SSL on your load balancer, and communicate over http between ELB and web instance.
This assumes you're running inside of a VPC of course.
As you scale having SSL terminated at your LB and internal traffic non-SSL will save you a great deal of overhead.
Using Cloudfront
Another option is to create a Cloudfront distribution in-front of your ELB, where your SSL connection is terminated at the nearest Edge Location. From Cloudfront to LLB(In a particular region) it uses AWS WAN so if you can live with that level of security, you can get better performance also with static content cached and delivered from Edge location. Another advantage is that you can get free SSL certificates from AWS for Cloudfront regardless of your ELB region.
For the DB Server, normally it kept inside the same VPN as the WebServer and not allowed for external access. So I don't see a great deal in putting a separate certificate for DB access within the private network unless you have specific regulatory requirements.
First question, so if I get this wrong somehow be kind.
We are using Route 53 with Amazon and have our primary front end servers behind an ELB. Our app also routes all requests through HTTPS. We are utilizing an offsite status page via statuspage.io.
What I am trying to accomplish is if the primary site goes down I'd like to have R53 redirect both the SSL and non-SSL traffic to our status page.
I originally had tried setting up a static page in S3 but still had issues with HTTPS requests made on our site.
Has anyone done this successfully? I imagine it has to be possible, but its definitely outside my realm of expertise.
Thank you very much for your time and help.
You are right, S3 website doesn't support HTTPS. However, CloudFront does[1]. What you can do is failover to CloudFront and have your origin be your S3 website or your statuspage.io.
Steps:
Create a distribution and set the CNAMEs to match your DNS entries.
Upload and associate your SSL cert with your distribution
Update failover target to be your CloudFront distribution and set it as an alias.
[1] http://aws.amazon.com/about-aws/whats-new/2014/03/05/amazon-cloudront-announces-sni-custom-ssl/
Route53 is managing the DNS which is not what you want to do (even if you'd change the DNS it would take TTL to sync). What you should do is use a combination of auto-scaling policies and health-checks. These health-checks will be performed by the ELB every 30 seconds and if two consecutive checks will fail it'll mark the instance as out-of-service and will stop directing traffic to it (the ELB is directing traffic to your instances in a round-robin manner).
Having more than one instance and using auto-scaling rules is the key: it will enable AWS to terminate the unhealthy instance and spin up a new instance instead (in the same ASG with the same AMI etc).
Does anyone know how AWS ELB with SSL work behind the scenes? Running an nslookup on my ELB's domain name I get 4 unique IP addresses. If my ELB is SSL enabled, is it possible for AWS to share these same IPs with other SSL enabled ELBs (not necessarily owned by me)?
As I understand it the hostname in a web request is inside of the encrypted web request for a https request. If this is the case, does AWS have to give each SSL-enabled ELB unique IP addresses that are never shared with anyone else's SSL ELB instance? Put another way -- does AWS give 4 unique IP addresses for every SSL ELB you've requested?
Does anyone know how AWS ELB with SSL work behind the scenes? [...] Put another way --
does AWS give 4 unique IP addresses for every SSL ELB you've
requested?
Elastic Load Balancing (ELB) employs a scalable architecture in itself, meaning the number of unique IP addresses assigned to your ELB does in fact vary depending on the capacity needs and respective scaling activities of your ELB, see section Scaling Elastic Load Balancers within Best Practices in Evaluating Elastic Load Balancing (which provides a pretty detailed explanation of the Architecture of the Elastic Load Balancing Service and How It Works):
The controller will also monitor the load balancers and manage the
capacity [...]. It increases
capacity by utilizing either larger resources (resources with higher
performance characteristics) or more individual resources. The Elastic
Load Balancing service will update the Domain Name System (DNS) record
of the load balancer when it scales so that the new resources have
their respective IP addresses registered in DNS. The DNS record that
is created includes a Time-to-Live (TTL) setting of 60 seconds,[...]. By default, Elastic Load Balancing will return multiple IP
addresses when clients perform a DNS resolution, with the records
being randomly ordered [...]. As the traffic
profile changes, the controller service will scale the load balancers
to handle more requests, scaling equally in all Availability Zones. [emphasis mine]
This is further detailed in section DNS Resolution, including an important tip for load testing an ELB setup:
When Elastic Load Balancing scales, it updates the DNS record with the
new list of IP addresses. [...] It is critical that you factor this
changing DNS record into your tests. If you do not ensure that DNS is
re-resolved or use multiple test clients to simulate increased load,
the test may continue to hit a single IP address when Elastic Load
Balancing has actually allocated many more IP addresses. [emphasis mine]
The entire topic is explored in much more detail within Shlomo Swidler's excellent analysis The “Elastic” in “Elastic Load Balancing”: ELB Elasticity and How to Test it, which meanwhile refers to the aforementioned Best Practices in Evaluating Elastic Load Balancing by AWS as well, basically confirming his analysis but lacking the illustrative step by step samples Shlomo provides.