如何检测是否已从ssl连接转发tcp连接？

Question

我正在处理的具体方案是尝试连接到AWS弹性负载均衡器后面的websocket连接,同时强制执行https/ssl而不是http/tcp.

要从http/s启用TCP/SSL升级,负载均衡器上的协议必须已设置为TCP而不是端口80上的HTTP和SSL而不是443上的HTTPS,这两者都使用80转发到80的实例端口TCP.

但是,将协议设置为TCP/SSL的副作用是x-forwarded-proto不再设置标头,如下所示:

Amazon Elastic负载均衡器未填充x-forwarded-proto标头

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

关于具体情况的更多细节:存在一个在其内部运行的Meteor.js进程的docker容器,该进程依次驻留在AWS Elastic Beanstalk应用程序中(默认情况下具有Nginx代理层,但这不是由于使用了仅仅从码头中心拉出容器定义的码头工具而无法访问,它位于上述ELB的后面.

最后,当请求通过ELB,Nginx和docker代理层时,我正在检查我的应用程序可用的标头,如果客户端的原始请求以http或https开头,则尝试计算出来

传入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'
}

传入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'
}

其中唯一看起来有点模糊的是upgrade-insecure-requests标题,但基于此

什么是"升级 - 不安全请求"HTTP标头？

我很确定不是.

也许我错过了一些东西......

Answer 1

如果问题实际上是“我怎样才能确保通过http访问我的网站的任何人都重定向到https / ssl”（实际上事实证明这就是我的意思），则可以通过

1. 设置Elastic Load Balancer，以将实例上的80上的HTTP转发到实例上的80上的HTTP（而不是以前的80上的TCP），然后将443上的HTTPS转发到实例上的80上的TCP。

2. 在协议检测期间“假设HTTPS / SSL”：即检查是否存在x-forwarded-proto，如果存在，则来自http请求，即301到https。如果不存在，请假设它是https，不要重定向它（在实践中，我觉得我最好在重定向之前检查该协议是否为http，但是在当前设置中，我很确定这是唯一的情况可能会发生）。