如何检测tcp连接是否已从ssl连接转发？ [英] How can I detect if a tcp connection has been forwarded from a ssl connection?

问题描述

我正在处理的具体情况是尝试连接到AWS弹性负载平衡器后面的websocket连接，同时执行https / ssl而不是http / tcp。

要启用来自http / s的TCP / SSL升级，负载均衡器上的协议必须设置为TCP，而不是端口80上的HTTP，而不是在443上的SSL而不是HTTPS，这两者都转发到80使用TCP。

但是，将协议设置为TCP / SSL的副作用是 x-forwarding-proto 标题不再设置，如下所示：

这使得使用http / tcp到https / ssl的任何传入请求的下一个挑战有些问题，因为这通常依赖于检查t他 x-forwarding-proto 头。

有关具体情况的更多细节：存在docker容器里面有一个Meteor.js进程，它依次在AWS Elastic Beanstalk应用程序（默认情况下具有一个Nginx代理层）中，但是由于使用了一个简单地拉一个容器的docker位于上述ELB之后的定义）。

最终我将在请求发生之前检查我的应用程序可用的标头通过ELB，Nginx和码头代理层，试图解决如果客户端发出的原始请求以http或https开始

传入 https：// 请求标头：

  {
主机：'whatever.elasticbeanstalk.com'，
'x-real-ip'：'999.99.99.99'，
'x-forwarding-for'：'999.99.99.99'，
 'cache-control'：'max-age = 0'，
 accept：'text / html，application / xhtml + xml，application / xml; q = 0.9，image / webp，* / *; q = '，
'upgrade-insecure-requests'：'1'，
'user-agent'：'Mozilla / 5.0（Macintosh; Intel Mac OS X 10_10_5）AppleWebKit / 537.36（KHTML，像Gecko）Chrome / 46.0.2490.80 Safari / 537.36'，
'accept-encoding'：'gzip，deflate，sdch'，
'accept-语言'：'en-US，en; q = 0.8'
} 
  

传入 http：// 请求标头：

  {
 host：'whatever.elasticbeanstalk.com'，
'x-real-ip'：'999.99.99.99'，
'x-forwarding-for'：'999.99.99.99' ，
'cache-control'：'max-age = 0'，
 accept：'image / webp，image / *，* / *; q = 0.8'，
'代理'：'Mozilla / 5.0（Macintosh; Intel Mac OS X 10_10_5）AppleWebKit / 537.36（KHTML，像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'：'星期一，2015年11月02日23:46:31 GMT'
 $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ 
 
 
 - 请求标题，但基于此
 
 
 
 什么是升级 - 不安全请求 HTTP标头？ 
 
 
 
我确定不行。
 
 
 
也许我错过了但是... ... 
解决方案
如果问题实际上是我如何确保任何人通过http访问我的网站被重定向到https / ssl（事实证明这是我的意思），这可以通过
 
 
 
设置弹性负载平衡器将实例上80上的HTTP转发到HTTP（而不是之前的80上的TCP），然后将443上的HTTPS转发到实例上的80上的TCP。
在检测协议期间
 
 
 
假设HTTPS / SSL：即检查是否存在 x-forwarding-proto ，如果是，它来自http请求，因此301到https。如果不存在，假设它是https，不要重定向（实际上，我觉得我可以检查以确保协议在重定向之前是http，但在目前的设置中，我确信这是唯一的场景可能会发生）。
 
 
 
 
The specific scenario I'm dealing with is attempting to connect to a websocket connection behind an AWS elastic load balancer, whilst enforcing https/ssl rather than http/tcp.

To enable the TCP/SSL upgrade from http/s, the protocol on the load balancer has necessarily been set to TCP rather than HTTP on port 80 and SSL rather than HTTPS on 443, both of which are forwarded onto the instance port of 80 using TCP.

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

Amazon Elastic load balancer is not populating x-forwarded-proto header

This makes the next challenge of 301ing any incoming requests using http/tcp to https/ssl somewhat problematic, as this typically relies on the inspecting the x-forwarded-proto header.

A little more detail on the specifics of the situation: there exists a docker container with a Meteor.js process running inside of it, which resides in turn within an AWS Elastic Beanstalk Application (which has an Nginx proxy layer by default, but this isn't accessible due to the use of docker which simply pulls a container definition from docker hub), which sits behind the aforementioned ELB.

Ultimately I'm left inspecting the headers that I have available to my application by the time the request has gone through the ELB, Nginx and docker agent layers, trying to work out if the original request made by the client started with http or https

Incoming https:// request headers:
{
    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 http:// request headers:
{
    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 of these that looks vaguely useful is the upgrade-insecure-requests header, but based on this 

What is the "Upgrade-Insecure-Requests" HTTP header?

I'm pretty sure it's not.

Maybe I'm missing something however...
解决方案
If the question is in fact "How can I ensure anyone visiting my website via http is redirected to https/ssl" (as indeed it turned out that this is what I meant), this is possible by

Setting the Elastic Load Balancer to forward HTTP on 80 to HTTP on 80 on the instance (rather than TCP on 80 as it was before) and then forward HTTPS on 443 to TCP on 80 on the instance.
"Assuming HTTPS/SSL" during the detection of the protocol: namely check if there exists an x-forwarded-proto, if it does, it's come from a http request, thus 301 to https. If one doesn't exist, assume it's https, don't redirect it (in practice I felt I might as well check to ensure the protocol was http before redirecting, but in the current set up I'm pretty sure that's the only scenario that can possibly occur).


                        
这篇关于如何检测tcp连接是否已从ssl连接转发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！