2012-10-04 21 views
19

Tengo una aplicación asp.net que funciona en https (SSL). Esto funciona bien en mi computadora local y en Amazon AWS (entorno de producción).En solicitud HTTPS, Request.IsSecureConnection return false

Pero cuando recibo esta aplicación en la oficina (para probarla) pasan cosas extrañas.

  1. puedo ver la https en el navegador y la señal de bloqueo.

  2. violinista que también muestra que la salida se cifra y se muestra el puerto 443.

  3. Pero HttpContext.Current.Request.IsSecureConnection vuelve

  4. Y HttpContext.Current.Request.Url.Scheme devuelve http falsas.

En la oficina que está utilizando el Firewall Juniper SSG y TMG 2010 (Forefront Threat Management Gateway 2010). Así que el servidor recibe la solicitud a través de Juniper y TMG 2010. Gracias de antemano.

Respuesta

15

Para reducir costos, sospecho que el certificado SSL está instalado en la Puerta de enlace TMG y que esta puerta de enlace simplemente está reescribiendo la solicitud al HTTP estándar al pasarlo al servidor web real. Entonces, cuando la solicitud llega a IIS y a su aplicación web, se trata de una solicitud HTTP simple estándar.

+0

Certificado SSL instalado en TMG –

+0

Muy bien, así que esto explica el comportamiento. TMG está reescribiendo la solicitud antes de pasarla al servidor web. –

+5

@JomyJohn si el SSL * finaliza * en el TMG, entonces ASP.NET es correcto: la solicitud que recibe ASP.NET no es https –

0

Bueno otra manera de comprobar es comprobar el puerto

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

Nota: comprobar qué puerto se utiliza para las conexiones seguras, por lo general es 443

+0

esto no funciona como el servidor web todavía ve la solicitud como el puerto 80. – Aki

+0

@Aki puede que tengas razón, pero en la descripción "Jomy "mencioné que en el violinista ve el puerto 443 .... –

+2

Creo que es porque Fiddler mostraría la solicitud entre el cliente y el equilibrador de carga que está encriptado (puerto 443). Pero la solicitud entre el equilibrador de carga y el servidor web mostrará el puerto 80 y eso es lo que ve ASP.NET. – Aki

12

Este tropezó mi después de la implementación en Amazon Elastic Beanstalk ambiente. No pude ver ninguna forma de hacer que el equilibrador de carga permita la solicitud de SSL directamente al servidor. En cambio, siempre terminaba el SSL en el equilibrador de carga y pasaba el HTTP normal al servidor.

Encontré esta documentación: Elastic Load Balancing Concepts - X-Forwarded Headers.

Básicamente, el equilibrador de carga inyecta un número adicional de HTTP Headers en cada solicitud antes de reenviarlo al servidor de servicios de fondo. El más relevante es X-Forwarded-Proto que rastrea el protocolo utilizado para conectarse desde el navegador del cliente al equilibrador de carga. Esto puede verificarse así:

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. 
} 
+0

Recurso relacionado: http://www.bugdebugzone.com/2013/12/identifying-https-or-ssl-connection-in.html –

Cuestiones relacionadas