What is SSL termination?
SSL termination is the term pointing to proxy servers or load balancers which accepts SSL/TLS connections however do not use the same while connecting to the back end servers. E.g. A load balancer exposed to the internet might accept HTTPS at port 443 but connects to backend servers via HTTP only. This is typically done to increase performance by avoiding the overheads of SSL/TLS encryption and certificate verifications etc but also typically when the back end servers are behind firewalls such that the proxy is connecting to them via a trusted network.
Gotcha’s
Typically, if you are using SSL you will configure the server in such a way that all requests over http gets redirected to their https version instead of just showing 404 or nasty forbidden errors, however, if you use SSL termination, your servers will always get non-secure connections and will never know whether users used a more secure channel or not. If your proxy / load balancer supports redirection capabilities to achieve the same, go for it and read the remainder of this article out of curiosity only as that by far is the best option to take.
I am going to take AWS ELB (the load balancer service in Amazon’s public cloud) as examples below, however, the same concept can be applied to anything else really.
AWS ELB Http Balancing
In case of Http AWS ELB, the load balancer adds the following headers to the request relayed to the back-end server:
X-Forwarded-For
Contains the IP address (v4 or v6) in a comma-delimited form in the following format:
X-Forwarded-For: <original client IP>, <first proxy IP>, <second proxy 2 IP>...
The original client IP is always first followed by an ordered comma-delimited list of proxies that the request went through, basically if the ELB received a request with this header already present it will simply add its own IP at the end of the comma-delimited list otherwise create an entry of it with the original client IP followed by its own IP.
X-Forwarded-Proto
This header contains the protocol of the request made by the client i.e. HTTP or HTTPS. E.g.:
X-Forwarded-Proto: <protocol name>
where protocol name can be “https” or “http”.
You can use this header value to determine whether the client communicated via SSL to the load balancer or not and handle redirections via the internet server like IIS etc.
X-Forwarded-Port
Contains the port number at which the client connected to the load balancer.
X-Forwarded-Port: <port number>
AWS ELB TCP Balancing
In case of TCP balacing the request headers are passed on as-is and no extra headers are added.
You can however enable proxy protocol version 1 defined @ http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt. Note that in case of version 1 which defines a human readable format does not give out whether the client was using SSL or not, however, you can use the port number information to indirectly deduce the protocol used. To do the latter develop a process where TCP load balancers use a specific port for secure communiations like 443.
For a detailed guide on how to enable this, go through the AWS doc @ http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html.