How to determine if a tcp connection was sent from an ssl connection?

Question

The specific scenario I came across is an attempt to connect to the websocket connection behind the AWS elastic load balancer, as well as force the use of https / ssl rather than http / tcp.

To enable TCP / SSL updating with http / s, the protocol on the load balancer must have been installed on TCP, and not on HTTP on port 80 and SSL, and not on HTTPS on 443, both of which are redirected to the instance port from 80 using TCP .

However, a side effect of installing the protocol on TCP / SSL is that the x-forwarded-proto header is no longer set, as here:

Amazon Elastic load balancer does not populate x-forwarded-proto header

This makes the following problem: 301ing any incoming requests using http / tcp in https / ssl is somewhat problematic, as this usually depends on checking the x-forwarded-proto header.

A little detailed information about the specifics of the situation: there is a docker container with the Meteor.js process running inside it, which, in turn, is located in the AWS Elastic Beanstalk application (which has a default Nginx proxy, but this is not available due to the use of docker , which simply pulls the definition of the container from the docker hub), which is located behind the aforementioned ELB.

Ultimately, I left checking the headers that I have for my application by the time the request went through the ELB, Nginx, and docker levels, trying to figure out if the initial request made by the client started with http or https

Incoming headers https:// :

 { host: 'whatever.elasticbeanstalk.com', 'x-real-ip': '999.99.99.99', 'x-forwarded-for': '999.99.99.99', 'cache-control': 'max-age=0', accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8', 'upgrade-insecure-requests': '1', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36', 'accept-encoding': 'gzip, deflate, sdch', 'accept-language': 'en-US,en;q=0.8' } 

Incoming request headers http:// :

 { host: 'whatever.elasticbeanstalk.com', 'x-real-ip': '999.99.99.99', 'x-forwarded-for': '999.99.99.99', 'cache-control': 'max-age=0', accept: 'image/webp,image/*,*/*;q=0.8', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36', 'accept-encoding': 'gzip, deflate, sdch', 'accept-language': 'en-US,en;q=0.8', 'if-none-match': '"141699-1446507991000"', 'if-modified-since': 'Mon, 02 Nov 2015 23:46:31 GMT' } 

The only one that looks vaguely useful is the upgrade-insecure-requests header, but based on that

What is the "Update-Unsecure-Requests" "HTTP Header?

I am sure that this is not so.

Maybe I'm missing something ...

Answer 1

If the question is really “How can I guarantee that someone who visits my site via http is redirected to https / ssl” (as it really turned out that this is what I had in mind), this is possible

• Configure elastic load balancing to redirect HTTP from 80 to HTTP to 80 in the instance (instead of TCP to 80, as it was before), and then forward HTTPS to 443 in TCP to 80 in the instance.

• "Accepting HTTPS / SSL" during protocol discovery: namely, if x-forwarded-proto exists, if so, it comes from an HTTP request, thus from 301 to https. If this does not exist, suppose it is https, do not redirect it (in practice, I felt that I could verify that the protocol was http before the redirection, but in the current setup I am sure that the only scenario is what can happen).

Answer 2

When you use TCP, the ELB will not enter HTTP headers such as x-forwarded-proto or x-forwarded-for. You can get what you need by setting up a proxy protocol .