c# - usehttpsredirection - En la solicitud HTTPS, Request.IsSecureConnection devuelve false

usekestrel net core

Question

Tengo una aplicación asp.net trabajando en https (SSL). Esto funciona bien en mi computadora local y en Amazon AWS (entorno de producción).

Pero cuando recibo esta aplicación en la oficina (para probar) suceden algunas cosas extrañas.

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

2. Fiddler también muestra que la salida está encriptada y muestra el puerto 443.

3. Pero HttpContext.Current.Request.IsSecureConnection devuelve falso

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

En la oficina estamos utilizando el firewall SSG de Juniper 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.

Answer 1

Bueno, otra forma de comprobar es comprobar el puerto.

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

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

Answer 2

Esto me disparó después de implementarlo en el entorno Elastic Beanstalk de Amazon. No pude ver ninguna forma de que el equilibrador de carga permitiera la solicitud de SSL directamente al servidor. En su lugar, siempre terminaba el SSL en el equilibrador de carga y pasaba http sin formato al servidor.

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

Esencialmente, el equilibrador de carga inyecta una cantidad de encabezados HTTP adicionales en cada solicitud antes de reenviarla 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 comprobarse 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.
}

Answer 3

Para reducir los 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 a HTTP estándar al pasarla al servidor web real. Entonces, en el momento en que la solicitud llegue a IIS y a su aplicación web, se convertirá en una solicitud simple y estándar de HTTP.