¿Por qué los navegadores muestran errores feos para los certificados SSL que no son de confianza?

Cuando se enfrentan por un certificado no es de confianza, cada navegador Sé muestra un error a todo volumen como esto:¿Por qué los navegadores muestran errores feos para los certificados SSL que no son de confianza?

Por qué es eso?

Esto desalienta a los desarrolladores web a utilizar una tecnología increíble como SSL por miedo a que los usuarios encuentren el sitio web extremadamente sombreado. Los sitios ilegítimos (es decir, phishing) funcionan bien en HTTP, por lo que no pueden ser una preocupación.

¿Por qué lo hacen parecer tan importante? ¿No está teniendo SSL aunque no sea de confianza, mejor que no tenerlo?

Parece que me están malinterpretando. Estoy en desacuerdo con el hecho de que los sitios HTTP no pueden ser más seguros que un sitio HTTPS, incluso si no son de confianza. HTTP no hace cifrado o identificación. Los phishers pueden hacer sus sitios en HTTP y no se muestran advertencias. De buena fe, estoy al menos encriptando el tráfico. ¿Cómo puede ser eso malo?

Fuente

2010-09-30 Confluence

¿Por qué mi automóvil hace una gran cosa si tengo una puerta abierta mientras conduzco por la autopista? La advertencia/precaución suele ser proporcional al peligro potencial. Los certificados SSL que no son de confianza son un peligro potencialmente grande. –

@Matt Esto es una analogía falsa. Es más como: mi automóvil no hace nada si no estoy usando un cinturón de seguridad (HTTP), pero comienza a hacer sonar la alarma si estoy usando un cinturón de seguridad (HTTPS). – Confluence

Si solo quiere ahorrar unos pocos dólares, mire estos enlaces: http://www.cacert.org/ | http://www.startssl.com/ –

SSL proporciona para la comunicación segura entre el cliente y el servidor, permitiendo autenticación mutua, el uso de firmas digitales de integridad y cifrado para la privacidad.

(apache ssl docs)

Sí, no veo nada de las autoridades de certificación terceras partes que todos los navegadores deben reconocer como "legítimo". Por supuesto, así es el mundo, así que si no quieres que la gente vea una página aterradora, debes obtener un certificado firmado por alguien que los navegadores reconocerán.

Si sólo está utilizando SSL para un pequeño grupo de personas o de cosas en la casa, puede hacer que la gente instala su certificado raíz en su navegador como un certificado de confianza. Esto funcionaría bastante bien en un lan, donde un administrador de red podría instalarlo en toda la red.

Puede sonar incómodo sugerir enviar su certificado a las personas para instalar, pero si lo piensa, ¿en qué confía más: un certificado que vino con su navegador porque esa autoridad pagó sus cuotas o un certificado enviado a usted personalmente por su administrador de servidor/gerente de cuenta/contacto interno?

Sólo por mierdas y risitas que pensé en incluir el texto mostrado por el "Ayúdame a entender" que aparece en la pantalla en el PO ...

cuando se conecta a una red segura sitio web, el servidor que aloja ese sitio presenta a su navegador algo llamado "certificado" para verificar su identidad. Este certificado contiene información de identidad, como la dirección del sitio web, que es verificada por un tercero en el que confía su computadora. Al verificar que la dirección del certificado coincida con la dirección del sitio web, es posible verificar que se está comunicando de forma segura con el sitio web que desea, y no con un tercero (como un atacante en su red).

Para una falta de coincidencia de dominio (por ejemplo, tratando de ir a un subdominio en un cert no comodín), este párrafo siguiente:

En este caso, la dirección que aparece en el certificado no coincide la dirección del sitio web al que intentó acceder su navegador. Una posible razón para esto es que sus comunicaciones están siendo interceptadas por un atacante que está presentando un certificado para un sitio web diferente, lo que causaría una falta de coincidencia. Otra posible razón es que el servidor está configurado para devolver el mismo certificado para varios sitios web, incluido el que está intentando visitar, aunque ese certificado no sea válido para todos esos sitios web. Chromium puede decir con certeza que ha llegado, pero no puede verificar que ese es el mismo sitio que foo.admin.example.com que desea alcanzar. Si continúa, Chromium no buscará ningún otro desajuste de nombre. En general, es mejor no pasar de este punto.

Si el certificado no está firmado por una autoridad de confianza, estos párrafos siguen en su lugar:

En este caso, el certificado no ha sido verificado por un tercero que confía tu equipo. Cualquiera puede crear un certificado que alegue ser el que elija, por lo que debe ser verificado por un tercero de confianza. Sin esa verificación, la información de identidad en el certificado no tiene sentido. Por lo tanto, no es posible verificar que se está comunicando con admin.example.com en lugar de un atacante que generó su propio certificado que afirma ser admin.example.com. No deberías avanzar más allá de este punto.

Sin embargo, si trabaja en una organización que genera sus propios certificados y está intentando conectarse a un sitio web interno de esa organización utilizando dicho certificado, es posible que pueda resolver este problema de forma segura. Puede importar el certificado raíz de su organización como un "certificado raíz", y luego los certificados emitidos o verificados por su organización serán de confianza y no verá este error la próxima vez que intente conectarse a un sitio web interno. Póngase en contacto con el personal de ayuda de su organización para obtener ayuda para agregar un nuevo certificado raíz a su computadora.

Creo que estos últimos párrafos son una buena respuesta a esta pregunta. ;)

Fuente

2010-09-30 02:43:58

Estoy de acuerdo, creo lo mismo y uso certificados autofirmados en ambos casos - LAN y clientes - instalando el certificado raíz en sus navegadores y hasta ahora todo el mundo está contento con eso porque saben que el certificado identificará mi servidor y dará una alerta para otro a menos que el propietario del servidor pirata piratee mi DNS y logre obtener un certificado de confianza en mi dominio y espero que ningún proveedor de certificados de confianza le proporcione uno. – laurent

El objetivo de SSL es que usted puede verificar que el sitio es quien dice ser. Si no se puede confiar en el certificado, es muy probable que el sitio no sea quien dice ser.

Una conexión cifrada es realmente solo una ventaja secundaria en ese sentido (es decir, puede encriptar la conexión sin el uso de certificados).

Fuente

2010-09-30 01:39:02

No es difícil obtener un certificado SSL legítimo. Estos errores ocurren cuando algo está mal con el certificado, ¡algo de lo que los usuarios definitivamente deberían estar conscientes! –

No estoy hablando de certs que no coinciden con el dominio (sí, eso es bastante malo). Estoy hablando de certs firmados por autoridades que no están en las CA de confianza del navegador (por ej .: autofirmadas) – Confluence

@Confluence: ¿cuál es la diferencia? Si puedo auto firmar un certificado que dice que soy "yourbank.com", ¿por qué * no * esperaba que arrojara un error? –

Lo hacen porque un certificado SSL no solo está destinado a asegurar la comunicación a través del cable. También es un medio para identificar la fuente del contenido que se está asegurando (el contenido seguro proveniente de un hombre en el ataque medio a través de un certificado falso no es muy útil).

A menos que un tercero valide que usted es quien dice ser, no hay buenas razones para confiar en que su información (que se envía a través de SSL) es más segura que si no estuviera usando SSL en El primer lugar.

Fuente

2010-09-30 01:40:34

¿Pero por qué tienen que mostrar el error?Claro, no se puede garantizar que un certificado "no confiable" sea más seguro que ningún SSL, pero no puede ser ** menos ** seguro. Por el contrario, ¿por qué no mostrar los errores de las páginas en HTTP? – Confluence

@Confluence: si espera un certificado que no es de confianza, no hay problema. Ignore el mensaje, avance y disfrute del cifrado. Pero si vas a un sitio de comercio electrónico, ingresas la información de tu tarjeta de crédito y ves un mensaje de certificación no confiable que detendría (tampoco enviaría esa información a través de HTTP normal). –

Entiendo eso. Los techies entienden eso. Pero para un usuario regular (90% de la población de Internet) simplemente se ve extremadamente sombreado. – Confluence

La gente supone que las conexiones https son seguras, lo suficientemente buenas para los detalles de su tarjeta de crédito y las contraseñas importantes. Un hombre en el medio puede interceptar la conexión SSL a su banco o PayPal y proporcionarle su propio certificado autofirmado o diferente en lugar del certificado real del banco. Es importante advertir a la gente en voz alta si tal ataque podría estar teniendo lugar.

Si un atacante usa un certificado falso para el dominio del banco, y lo firma por alguna CA poco fiable que no verifica las cosas correctamente, puede interceptar el tráfico SSL a su banco y usted no será más inteligente, solo un poquito más pobre. Sin la advertencia emergente, no hay necesidad de una AC dudosa, y la banca por Internet y el comercio electrónico serían totalmente inseguros.

Fuente

2010-09-30 01:44:51

Ese no es el problema. Estoy hablando de tener un certificado autofirmado que coincida con un dominio que poseo, que un usuario desee visitar. – Confluence

@Confluence: ¿En qué se diferencia esa situación de un operador malintencionado que ejecuta un sitio que posee, con un certificado autofirmado que se hace pasar por un sitio de banca en línea * que el usuario visita voluntariamente *? –

Si no avisaran sobre su certificado, tampoco podrían advertir sobre el certificado de ataque MITM. –

A juzgar por sus comentarios, puedo ver que está confundido entre lo que cree que las personas dicen y lo que realmente dicen.

¿Por qué lo hacen parecer tan importante? ¿No está teniendo SSL aunque no sea de confianza, mejor que no tenerlo?

¿Pero por qué tienen que mostrar el error? Claro, no se puede garantizar que un certificado "no confiable" sea más seguro que ningún SSL, pero no puede ser menos seguro.

Si solo está interesado en una conexión cifrada, sí, esto es cierto. Pero SSL está diseñado para un objetivo adicional: identificación. Por lo tanto, certificados.

No estoy hablando de certs que no coinciden con el dominio (sí, eso es bastante malo). Estoy hablando de certs firmados por autoridades que no están en las CA confiables del navegador (p. Ej .: autofirmados)

¿Cómo puede confiar en el certificado si no es de confianza para nadie de su confianza?

Editar

La necesidad de prevenir man-in-the-middle surge debido a que está intentando establecer una conexión privilegiada.

Lo que necesita comprender es que con HTTP simple, no hay absolutamente ninguna promesa de seguridad, y cualquiera puede leer los contenidos transmitidos a través de la conexión. Por lo tanto, no pasa información sensible. No hay necesidad de una advertencia porque no está transfiriendo información confidencial.

Cuando utiliza HTTPS, el navegador asume que va a transferir información confidencial, de lo contrario, estaría utilizando HTTP sin formato. Por lo tanto, hace un gran escándalo cuando no puede verificar la identidad del servidor.

Fuente

2010-09-30 01:55:11

Mi carne de res principal es con el mensaje de error. El HTTP no encriptado tampoco hace ninguna identificación, pero ningún navegador advertirá al usuario sobre eso. – Confluence

Como HTTP no está encriptado, cualquiera puede interceptar el contenido, por lo que los ataques de intermediarios no tienen sentido. Al establecer una conexión cifrada de uno a uno, ¡debe asegurarse de establecer la conexión con la persona adecuada! –

Ese es exactamente mi punto. HTTP => totalmente inseguro, sin advertencia. HTTPS con cert sin confianza => posiblemente inseguro, gran advertencia. – Confluence

¿Por qué es eso?

Porque la mayoría de las personas no leen. No saben qué significa https. Un gran error es OBLIGATORIO para que la gente lo lea.

Esto desalienta a los desarrolladores web a usar una tecnología increíble como SSL por temor a que los usuarios encuentren el sitio web extremadamente sombreado.

No, no lo hace. ¿Tienes alguna evidencia para eso? Esa afirmación es ridícula.

Esto alienta fuertemente desarrolladores y usuarios saber quién están tratando.

"teme que los usuarios encontrarán el sitio web muy sombrío"

lo que hace este incluso? ¿Quiere decir "temores de que falta de un certificado significa que los usuarios de encontrarán el sitio web extremadamente sombreado"?

Eso no es un "miedo": ese es el objetivo.

El objetivo es que "falta de un certificado significa que los usuarios de encontrarán el sitio web extremadamente sombreado" Ese es el propósito.

Fuente

2010-09-30 02:15:24

'El objetivo es que' la falta de un certificado signifique que los usuarios encontrarán el sitio web extremadamente sombreado '. Ese es el propósito'. Entonces, ¿por qué no se muestran estas advertencias a los usuarios que visitan los sitios HTTP habituales? – Confluence

@Confluence: probablemente * debería * recibir advertencias sobre páginas no encriptadas, pero solo para páginas con datos confidenciales. El truco es, ¿cómo sabe el navegador si hay datos confidenciales? Podría buscar entradas de contraseña, pero eso no cubriría todo. Creo que con HTTPS se supone que hay algunos datos privados que se intercambian, por lo que esto pone al navegador en alerta máxima para cosas que parecen sospechosas. –

@Confluence: "Entonces, ¿por qué no se muestran estas advertencias a los usuarios que visitan los sitios HTTP habituales?" Debido a que el certificado no está ** mal **, falta. Hay un problema lógico al presentar un error cuando (a) no hay certificación y (b) no se esperaba ningún certificado. Si intenta utilizar IE en modo "seguro" en una versión no profesional de Windows, verá que IE proporciona todo tipo de alertas y advertencias en lugares y momentos aleatorios. El problema es simple lógica. 'http' no tiene expectativa de certificación, por lo que no puede haber un error. –

¿Por qué es eso?

Porque si hay un sitio que se hace pasar por un sitio de fiar, que realmente quiere saber sobre él como usuario!

Mira, una conexión segura con el atacante no es del todo buena, y cada hombre y su perro pueden hacer un certificado autofirmado. No hay no confianza inherente en un certificado autofirmado de nadie, a excepción de las raíces de confianza que tiene instaladas en su navegador. El creador del navegador selecciona el conjunto predeterminado de raíces de confianza (¡con cuidado!) Con el objetivo de que el sistema confíe únicamente en las CA que solo actúan de forma segura, y esto funciona principalmente. También puede agregar sus propias raíces de confianza, y si está usando una CA privada para realizar pruebas, entonces debería hacerlo.

Esto es claramente hostil a los desarrolladores web para utilizar una tecnología impresionante como SSL por temor a que los usuarios encontrarán el sitio web muy sombrío. Los sitios ilegítimos (es decir, phishing) funcionan bien en HTTP, por lo que no pueden ser una preocupación.

¿Qué ?! Puede obtener un certificado legítimo por muy poco. Puede configurar su propia raíz de confianza de forma gratuita (más algunos trabajos). Cualquiera que se lamente y se lamente acerca de este tema es simplemente flojo y/o demasiado barato y no simpatizo con tales actitudes.

Lo ideal es que un navegador busque la información que desea mantener segura (como cosas que parecen números de tarjetas de crédito) y eche ese tipo de advertencia si hubo un intento de enviar esos datos en una situación insegura o inadecuadamente segura canal. Por desgracia, es difícil saber, por simple inspección, si los datos son privados o no; así como no existe un bit EVIL, tampoco hay un bit de PRIVATE. (Tal vez un sistema de metadatos generalizado podría hacerlo ... Sí, claro. Olvídalo.) Así que solo hacen lo mejor que pueden y marcan situaciones donde es muy probable que haya un problema.

¿Por qué lo hacen parecer tan importante? ¿No está teniendo SSL aunque no sea de confianza, mejor que no tenerlo?

¿Con qué modelo de amenaza está lidiando?

Los fabricantes de navegadores se han centrado en el caso en que cualquiera puede sintetizar un certificado SSL (porque de hecho ese es el caso) y los hacks DNS son demasiado comunes; La combinación de estos medios es que no puede saber que la dirección IP que tiene para un nombre de host corresponde al propietario legítimo de ese dominio, y cualquiera puede reclamar poseer ese dominio. Ah, pero en su lugar confían en que una CA al menos verifique que estén emitiendo el certificado a la persona adecuada y eso a su vez es suficiente (más algunas otras cosas) para que sea posible determinar si usted está hablando con la persona adecuada. propietario legítimo del dominio; proporciona una base para todo el resto de la confianza involucrada en una conversación segura. Esperemos que el banco haya utilizado otras comunicaciones no bloqueables (por ejemplo, una carta enviada por correo) para decirle a la gente que verifique que la identidad del sitio sea correcta (EV certs ayuda un poco aquí) pero eso todavía es un poco de curita dada qué tan insuspiciosos son algunos usuarios.

Los problemas con esto provienen de los CA que no aplican los controles adecuados (francamente, deberían ser expulsados del tren de salsa por no cumplir con su deber) y los usuarios que le contarán algo a alguien. No se puede evitar que se publicar deliberadamente su propia CC# en un foro público a cargo de algunos personajes sospechosos de Smolensk ^[1], no importa lo estúpido que es una idea ...

^{[1 ]} No es que haya nada malo en esa ciudad. El punto sería el mismo si lo sustituyeses por Tallahassee, Ballarat, Lagos, Chonqing, Bogotá, Salerno, Durban, Mumbai, ... Hay basura por todas partes.

Fuente

2010-10-03 23:02:14

¿Por qué los navegadores muestran errores feos para los certificados SSL que no son de confianza?

Respuesta

Cuestiones relacionadas