Evitar SSL "Estás a punto de ser redireccionado a una conexión que no es segura." mensaje

Question

Tengo una pantalla de inicio de sesión que se sirve a través de SSL. El usuario rellena su nombre de usuario/contraseña, esto se transfiere al servidor. En este punto, quiero saltar de SSL, así que los redirijo a la misma página sin SSL.

Esto hace que el navegador muestre un cuadro de diálogo de advertencia "Está a punto de ser redirigido a una conexión que no es segura". ¿Cómo puedo evitar esto? He tenido muchos sitios como el correo yahoo y gmail que te dan una página SSL para iniciar sesión, luego te envío a una página que no es SSL después de esto.

Pregunta secundaria: ¿cuál es el propósito de este diálogo? Está tratando de advertirme sobre algún propósito nefasto, pero ¿qué hay de malo en redirigir a alguien a una página que no sea SSL? No recibo una advertencia cuando estoy en una página SSL y hago clic en un enlace que no sea SSL. ¿Qué hay de diferente en redirigir a alguien?

Estoy haciendo esto en ASP.NET 2.0, pero creo que esta es una pregunta genérica de desarrollo web.

ACTUALIZAR RESUMEN: Parece que la respuesta popular es "NO EVITARLO". Puedo entender que un usuario debería recibir un mensaje cuando se elimine la seguridad. Pero no obtengo un diálogo cuando sigo un enlace y se elimina la seguridad, por lo que al menos diría que esto es inconsistente.

Las versiones de diálogo/navegador. De hecho, no veo el diálogo en IE7/FF3 (tal vez he hecho clic en una casilla de verificación para evitarlo). Lo que es más importante, el cliente SI LO ve en IE6, sin una casilla de verificación para eliminarlo (sí, sé que IE6 es viejo y una mierda).

Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg

IE6: IE6 http://img188.imageshack.us/img188/139/sslwarningie6.jpg

La alternativa: hacer que todo el sitio SSL, nunca se redirigir al usuario de SSL. Podría manejar eso. Pero tengo un cliente semi-técnico que tiene algunos puntos bastante buenos:

• "SSL va a causar un aumento en el tráfico/potencia de procesamiento". Realmente no me compro esto, y no creo que su sitio necesite más de una caja para atenderlo.
• "Yahoo lo hace. Yahoo es una gran empresa técnica. ¿Eres más inteligente que Yahoo?"

Voy a intentar influir en el cliente a un sitio totalmente SSL. Argumentaré que el enfoque de Yahoo tenía sentido en 1996, o para un sitio que es MUCHO más popular. Algunos enlaces oficiales que explican por qué sucede este diálogo ayudarían (es decir, el nivel de autenticidad de Jakob Nielsen).

Answer 1

¡Utilice SSL para toda la página en primer lugar!

No hay nada de malo con SSL. Debe proporcionar la privacidad del usuario en todas partes, no solo al iniciar sesión. Tiene sentido un sitio completo. Simplemente redirija todas las páginas que no son SSL a páginas SSL y mantenga todo SSL.

Answer 2

En cuanto a la finalidad: es para que sepa que su conexión ya no estará encriptada SSL. Es posible que haya visto antes que la conexión está cifrada y puede pensar que todavía lo está, por lo que esta advertencia dice "Para que quede claro, los datos que envíe a partir de ahora serán texto claro".

En cuanto a cómo suprimirlo: AFAIK no puede, es una cosa del navegador, ¿cuál sería el sentido del mensaje de lo contrario? Aunque existen soluciones como las redirecciones del lado del cliente, no creo que deba tratar de evitar los "problemas" del cliente como este. Si el navegador elige ser detallado, déjalo. Hay una casilla de verificación "No mostrar esto otra vez" en el cuadro de diálogo después de Si el usuario desea suprimir este mensaje, puede hacerlo fácilmente, y tal vez realmente le gusta verlo.
Además, en mi humilde opinión, si el navegador valía la pena, todavía aparecería esta advertencia, incluso si utilizaba trucos de redirección del lado del cliente.

Answer 3

"¿Cómo puedo evitar esto?"

¡No deberías!

Aunque podría intentarlo con JavaScript. Esto podría funcionar en algunos navegadores y fallar en otros.

"¿Cuál es el propósito de este diálogo?"

Advierte porque el usuario suele pasar por alto el cambio entre SSL y no SSL en los sitios web. No se emite una advertencia sobre "no SSL a SSL", ya que aumenta la seguridad y la privacidad. Sin embargo, cuando la seguridad de repente disminuyó, el usuario debe notar que rápidamente, a fin de evitar una falsa sensación de seguridad. De hecho, el redireccionamiento a un sitio que no es SSL a veces se usa en ataques XSS/MITM.

"SSL va a causar un aumento en el tráfico de potencia/procesamiento"

Esto no tiene sentido. Puede ser cierto para sitios llenos de contenido grande y estático. Sin embargo, para aplicaciones web dinámicas normales, el cifrado es muy barato en comparación con la lógica de negocios, acceso a bases de datos, etc.

Hay una leyenda urbana que dice que el contenido SSL no está marcado por los navegadores. Consulte "Will web browsers cache content over https" para obtener más información.

"Yahoo lo hace. Yahoo es una gran compañía técnica. ¿Eres más inteligente que Yahoo?"

cierta retórica contra-preguntas:

• ¿Es una empresa técnica grande como Yahoo?
• ¿Ser una gran empresa técnica impidió que Microsoft produjera software malicioso?
• ¿Tienes que admitir navegadores viejos y defectuosos (con SSL roto), como Yahoo tiene que hacerlo?

Answer 4

He golpeado este mismo problema hace un tiempo. Así que eché un vistazo al violín para ver cómo lo hace el correo yahoo. Este es el paso que vi (y utilicé en mi sitio):

El usuario completa el formulario encriptado SSL y las POST en el servidor. Servidor autentica, y escupe una secuencia de comandos para redirigir el cliente

<script language="JavaScript"> 
<!-- 
window.location.replace("~~ non-SSL URL ~~"); 
// --> 
</script> 

Calculo el código del lado del cliente está ahí para evitar este cuadro de diálogo.

Answer 5

Gmail, yahoo, etc. usan SSL para un iframe cifrado, que autentica, pero no hay ninguna redirección en la página de la que está hablando. La página completa no está encriptada para estos sistemas de inicio de sesión.

Answer 6

El ataque al que se está previniendo es una sesión de sesión de SSL man-in-the-middle. El mensaje está ahí con una buena causa.

Answer 7

Simplemente señale a su cliente a los últimos ataques contra el contenido en modo mixto (búsqueda CookieMonster en fscked.org) y ataques proxy (contra sitios disponibles tanto en http como en https, búsqueda Pretty-Bad-Proxy). Él podría reconsiderarlo.

Es mucho más fácil obtener la seguridad correcta si solo se trata de un protocolo sin mezclar los dos. SSL agrega un poco de sobrecarga, pero no es nada en comparación con el costo de una infracción.

Answer 8

leído: http://support.microsoft.com/kb/883740 que dice que esto se soluciona en una revisión o con una configuración de registro modificada. Sin embargo, no todas las CPU de IE6 que utilizamos tienen este problema, ni su configuración de registro corresponde a lo que este artículo dice que deberían. También algunos que dan el msg son XPsp3 e IE6 sp3.

Tenemos una pantalla de inicio de sesión https que utiliza el código para iniciar sesión en otros 15 dominios (http) y algunos de nuestros usuarios de IE6 tienen que hacer clic en "Sí" 15 veces. Esto es inaceptable para ellos. No, no podemos controlar qué navegador usan todos nuestros usuarios. Algunos no son compatibles con la actualización a IE7.

Estamos buscando algún atributo de configuración para cada usuario para ajustar que suprimirá este mensaje. Inmediatamente hemos configed un navegador "malo" con configuraciones que coinciden con uno que no da el mensaje. Seguridad de Internet e Intranet y configuraciones avanzadas y Proxies (ninguno). También conexiones de red. No hay alegría hasta el momento.

¿Alguna idea?