在HTTPS请求中，Request.IsSecureConnection返回false

我有一个在https（SSL）中工作的asp.net应用程序。 这在我的本地计算机和Amazon AWS（生产环境）中运行良好。

但是当我在办公室托管这个应用程序（用于测试）时，会发生一些奇怪的事情

1. 我可以在浏览器和锁定标志中看到https 。

2. Fiddler还显示输出已加密并显示端口443。

3. 但是HttpContext.Current.Request.IsSecureConnection返回false

4. 并且HttpContext.Current.Request.Url.Scheme返回http 。

在办公室，我们使用的是Juniper SSG防火墙和TMG 2010（Forefront Threat Management Gateway 2010）。 因此服务器通过Juniper和TMG 2010接收请求。提前感谢。

Answer 1

为了降低成本，我怀疑在TMG网关上安装了SSL证书，并且该网关只是在将请求传递给实际的Web服务器时将请求重写为标准HTTP。 因此，当请求到达IIS和您的Web应用程序时，它是标准的纯HTTP请求。

Answer 2

在部署到Amazon的Elastic Beanstalk环境之后，这让我失望了。 我看不出任何方法让负载均衡器允许SSL请求直接进入服务器。 相反，它始终在负载均衡器处终止SSL并将普通的http传递回服务器。

我找到了这个文档： Elastic Load Balancing Concepts – X-Forwarded Headers 。

本质上，负载均衡器会在将每个请求转发到后端服务器之前为每个请求注入大量额外的HTTP标头 。 最相关的是X-Forwarded-Proto ，它跟踪用于从客户端浏览器连接到负载均衡器的协议。 这可以像这样检查：

 var loadbalancerReceivedSSLRequest = string.Equals(Request.Headers["X-Forwarded-Proto"], "https"); var serverReceivedSSLRequest = Request.IsSecureConnection; if (loadbalancerReceivedSSLRequest || serverReceivedSSLRequest) { // SSL in use. } else { // SSL not in use. } 

Answer 3

另一种检查方法是检查端口

 if(context.Request.Url.Port == 443) 

注意：检查哪个端口用于安全连接，通常是443