Re:TLS Termination for Network Load Balancers
by DGAP on Thursday January 24, 2019 @03:57PM
(#18992876)
This further reinforces the pattern of terminating TLS at the LB. While this is generally justifiable, it does decrease defense-in-depth.
[ Parent
| on HN ]
Re:TLS Termination for Network Load Balancers
by jontro on Thursday January 24, 2019 @04:11PM
(#18993005)
After choosing the certificate and the policy, I click Next:Configure Routing. I can choose the communication protocol (TCP or TLS) that will be used between my NLB and my targets. If I choose TLS, communication is encrypted; this allows you to make use of complete end-to-end encryption in transit:
You can still communicate over ssl internally. What do you mean with it will decreases the defence?
Re:TLS Termination for Network Load Balancers
by scarface74 on Thursday January 24, 2019 @04:23PM
(#18993110)
But then what’s the purpose of terminating at the LB? The two advantages are that it takes the load off of your web server having to decrypt traffic and autorenwal of SSL certs. Once you have to manage your own certs and decrypt at your server, both of those advantages are removed.
Re:TLS Termination for Network Load Balancers
by jontro on Thursday January 24, 2019 @04:29PM
(#18993172)
Having the public facing certificate managed by acm and not worrying about deploying those on the instances is a win. I'm not sure how the certificate validation is done LB <-> instance, but if you can have a private CA and use that for intra-communication it would still keep everything encrypted properly
Re:TLS Termination for Network Load Balancers
by dc_gregory on Thursday January 24, 2019 @04:29PM
(#18993181)
Auto generated self signed certs on the servers
Re:TLS Termination for Network Load Balancers
by scarface74 on Thursday January 24, 2019 @04:21PM
(#18993094)
What’s the threat model for someone intercepting traffic between a load balancer and an EC2 instance?
Re:TLS Termination for Network Load Balancers
by illumin8 on Thursday January 24, 2019 @11:28PM
(#18995565)
Please see this tweet from an AWS principal engineer:
https://twitter.com/colmmacc/status/1088516445145784320
"... well, NLB runs on Amazon VPC. On VPC we encapsulate, authenticate and secure traffic at the packet level. Packets can't be spoofed or MITMd on VPC. Traffic only goes where you send it. That makes it possible to use a self-signed, or even expired, certificate on your end."
Re:TLS Termination for Network Load Balancers
by zokier on Thursday January 24, 2019 @05:59PM
(#18993930)
That is generally AWS stance on the matter too; VPC is considered secure enough. I remember reading something about it in their own blog, but now I could only find this where it is explained:
Re:TLS Termination for Network Load Balancers
by scarface74 on Thursday January 24, 2019 @06:17PM
(#18994037)
I’ve watched the reinvent videos where they describe the custom hardware NICs they use with their own custom ARM chips to ensure security and that traffic isn’t spoofed.
Re:TLS Termination for Network Load Balancers
by outworlder on Thursday January 24, 2019 @05:30PM
(#18993712)
I'd like to know too. This seems like a case of being on the other side of the airtight hatchway.
https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
Re:TLS Termination for Network Load Balancers
by tmd83 on Thursday January 24, 2019 @08:10PM
(#18994653)
What's the threat vector if it's not a cloud environment? Also if you have access to either the LB or host wouldn't you get access to the certificate there anyway to decrypt the traffic?
Re:TLS Termination for Network Load Balancers
by scarface74 on Thursday January 24, 2019 @08:47PM
(#18994833)
I agree. Realistically, it’s just as safe to do ssl termination at the LB. However, it’s generally interpreted that to meet certain security compliance’s like HIPAA you have to have end to end encryption and encryption at rest.
Someone posted a quoted from the HIPAA regulations where it could be interpreted as not being the case. I don’t think I would risk taking that chance though from a compliance standpoint.