Security/Server Side TLS: Difference between revisions

Jump to navigation Jump to search

Security/Server Side TLS (view source)

Revision as of 01:08, 28 February 2014

893 bytes removed ,  28 February 2014
revisit ELB capabilities
mNo edit summary
(revisit ELB capabilities)
Line 11: Line 11:
|-  
|-  
|  <span style="color:green;">'''READY'''</span> ||
|  <span style="color:green;">'''READY'''</span> ||
* Version 2.5.1: ulfr: Revisit ELB capabilities
* Version 2.5: ulfr: Update ZLB information for OCSP Stapling and ciphersuite
* Version 2.5: ulfr: Update ZLB information for OCSP Stapling and ciphersuite
* Version 2.4: ulfr: Moved a couple of aes128 above aes256 in the ciphersuite
* Version 2.4: ulfr: Moved a couple of aes128 above aes256 in the ciphersuite
Line 305: Line 306:
== Amazon Web Services Elastic Load Balancer (AWS ELB) ==
== Amazon Web Services Elastic Load Balancer (AWS ELB) ==


ELBs support TLS 1.2, but lack support for ciphers ordering, custom DH parameters and OCSP Stapling.
The ELB service support TLS 1.2 and ciphers ordering. It lacks support for custom DH parameters and OCSP Stapling.
The default configuration of ELBs doesn't enable the correct ciphers or versions of TLS. This can be done by hand in the Web Console, but is tedious. Gene Wood, from Identity Ops, wrote a script that configures the proper TLS policy on ELB: https://github.com/mozilla/identity-ops/blob/master/aws-tools/apply_security_assurance_elb_ciphersuite_policy.py


Because of the lack of server side ordering, it is preferable to terminate TLS connection on something else than ELBs. ELBs can be used at layer 4 to load balance TCP connections, and terminate SSL on Nginx, Apache or any suitable TLS stack.
The default configuration of ELBs has sane settings, that can be customized in the Web Console or via the API. We do still recommend that you enforce the ciphersuite using this script: https://github.com/mozilla/identity-ops/blob/master/aws-tools/apply_security_assurance_elb_ciphersuite_policy.py
When using ELBs as L4 load balancer, the following limitations apply:
 
* Client IP will be hidden to the backend servers. The application behind the ELB will only see the IP of the ELB. Headers such as X-Forwarded-For cannot be used to store the client IP, because the ELB does not decrypt the SSL.
If you want better control over TLS than ELB provide, another option in AWS is to terminate SSL on HAproxy, using the PROXY protocol between ELB and HAproxy. http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
* Only layer 4 type heartbeats can be used (connection establishment on target port).
* Session stickiness will only be possible by source IP: one source IP will always reach the same application server. Session stickiness via cookie cannot be used, because the ELB does not decrypt the SSL.
ELBs support HAproxy's proxy protocol, that removes the need for X-Forwarded-For and operates with a header placed right before the TCP packet. While still in beta, a solution composed of L4 ELBs that send TCP traffic to HAproxy for SSL termination would solve the limitations above.


== Zeus Load Balancer(Riverbed Stingray) ==
== Zeus Load Balancer(Riverbed Stingray) ==
Ulfr
Confirmed users
529

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/942461"

Navigation menu