¿Cuál es la diferencia entre http y https con un certificado SSL autofirmado?

El propósito de la advertencia es que al usar HTTPS, existe la expectativa de una seguridad adecuada, pero un certificado autofirmado o caducado tiene vulnerabilidades que el usuario debe conocer.

El "riesgo" es que uno piensa que están bien asegurados, pero no están completamente protegidos, a diferencia de HTTP, donde se sabe que no hay cifrado en absoluto.

No habría una advertencia para HTTP, porque no hay seguridad (es decir, cifrado) que pueda comprometer.

Diferencia de seguridad

Primero, hablemos de SSL (ahora llamado TLS por cierto), que agrega la 'S' al final de HTTP S y está a cargo de " asegurar la comunicación ". La clave para responder a esta pregunta es, de hecho, comprender completamente lo que queremos decir con "asegurar la comunicación".

SSL, sin importar si se trata de un certificado autofirmado que está siendo usado o firmado por una CA de confianza, garantizará que la comunicación entre usted y el host remoto sea confidencial y que nadie pueda manipular los datos intercambiados. .

Por lo tanto, la advertencia no se trata de eso.

Sin embargo, ¿cómo puede estar seguro de que este host remoto que responde a sus solicitudes es realmente quien espera que sea? Con los sitios web públicos, para los cuales no tiene una forma directa de autenticar el certificado solo, es simplemente imposible. Aquí viene una CA de confianza externa: al confiar en una CA, usted asume que todos los certificados firmados por él se usan solo con fines legítimos para proteger el tráfico con los servidores mencionados explícitamente en el certificado.

Esto es todo de lo que se trata esta advertencia: su navegador le advierte que, si bien la comunicación en sí es segura, no tiene una forma automática de autenticar el certificado por sí misma y, por lo tanto, confía en que lo acepte o lo rechace.

Si el certificado autofirmado está asociado a uno de sus servidores, debería poder continuar con esta autenticación manual: debería poder verificar la huella digital del certificado, o al menos debería saber si el certificado ha sido modificado. Recientemente o no.

Una vez que se haya realizado esta autenticación manual, su navegador le ofrece la posibilidad de "recordar" este certificado: esto significa que el navegador asociará este certificado autofirmado al host de URL y no le avisará en el futuro desde ahora. , el navegador tiene una forma automatizada de autenticar el certificado.

Sin embargo, tan pronto como el certificado autofirmado se modifique en el servidor, el navegador mostrará nuevamente la advertencia, y de nuevo dependerá del usuario final determinar si este cambio del certificado es normal y si El nuevo certificado presentado por el servidor es realmente genuino.

diferencia de UX

Mi respuesta no cubría el aspecto de la interfaz de usuario del navegador de su pregunta hasta ahora.

Encontré que la forma predeterminada en que el navegador informa a los usuarios acerca de la seguridad actual es, en su mayoría, ineficaz. El usuario solo no se preocupa por el candado , y no se da cuenta cuando falta la seguridad SSL . Incluso los usuarios a los que les importa no tienen acceso a la información correcta (nada impide que un sitio web muestre un Certificado de Validación Extendida para configurar su sitio web para usar sistemas de criptografía deficientes y débiles o para confiar en el contenido de terceros menos seguro: la interfaz del navegador por defecto aún estará feliz y mostrará la barra verde de "seguridad de primera categoría".

Con suerte, dependiendo del navegador utilizado, puede haber algunos complementos que intenten remediar esta situación. En Firefox, tiene SSLeuth que, de forma predeterminada, agregará un área de notificación nueva a la izquierda o la barra de URL (junto al candado cuando hay uno)

Esta nueva área de notificación tiene las siguientes propiedades:

• El color de fondo varía de rojo (sin seguridad: HTTP), de naranja (configuración de seguridad deficiente) a azul y verde (seguridad buena y mejor según las mejores prácticas actuales).
• Una opción permite extender este color a toda la barra de URL, por lo que los sitios web HTTP ahora mostrarán una barra de URL completamente roja,
• Por último, se muestra una puntuación (entre 0 y 10) para mostrar una estimación del nivel de seguridad SSL / TLS actual. Tiene en cuenta varios criterios, entre ellos el tipo de certificado (autofirmado, firmado por CA, certificado de validación extendida), la configuración criptográfica utilizada, la seguridad del contenido de terceros, etc. Al hacer clic en el área de notificación se proporcionan todos los detalles de puntuación, principalmente útil cuando el resultado no es el esperado (también conocido como " ¿Por qué a mi sitio web bancario se le otorga una barra naranja de URL? ").

Sin advertencias sobre cosas como los certificados aut caducados o caducados, las selecciones de conjuntos de cifrado inadecuados y otras configuraciones incorrectas de HTTPS, la presentación del estado de seguridad de un sitio web al usuario se convierte en binaria: o tiene HTTPS en el sitio o no lo hagas Esto ocultaría una serie de matices que pueden afectar significativamente la cantidad de "S" en "HTTPS" que realmente lo protege.

En una implementación adecuada de HTTPS, el certificado del sitio está firmado por un tercero en el que el sistema cliente confía. Esto garantiza al cliente que el contenido se entrega desde el sistema que espera y que no hay nadie en el medio.

El problema con un certificado autofirmado es que cualquiera puede hacer uno. Por lo tanto, ese certificado podría ser generado a partir de un sistema que actúa como Hombre en el Medio que está interceptando y posiblemente incluso manipulando los datos entre usted y el sistema de confianza. Si el sistema de confianza normalmente utiliza un certificado autofirmado y no ha validado personalmente ese certificado fuera de banda o durante una conexión anterior de confianza conocida, nunca notará la diferencia.

¿En qué se diferencia esto de HTTP regular? A primera vista, puede parecer que no lo es: en cualquiera de los dos escenarios, un MitM puede ver y manipular la conexión con bastante facilidad y usted sería ajeno. Sin embargo, el uso de HTTPS con un certificado autofirmado le ofrece algo que HTTP no puede: La seguridad de que sus datos aún están encriptados durante la transmisión, a pesar de que haya alguien entre ellos. Dependiendo del entorno (p. Ej., Wi-Fi público densamente poblado), esto podría reducir drásticamente la audiencia que tiene acceso a sus datos, incluso cuando en realidad puede haber un MitM en juego.

Es posible que desee revisar mi respuesta en otra pregunta relacionada para más cobertura sobre esto. El artículo de Troy Hunt, "SSL no es sobre cifrado" puede ser de interés para usted, aunque quizás no sea muy útil para su lado del debate aquí.

Estas respuestas son geniales. Pero a menudo tengo que dar una respuesta simplificada sin toda la jerga.

HTTP: no está cifrado y los datos enviados a través de la línea se pueden leer fácilmente.

HTTPS: una parte confiable, encriptada y verificada, los datos están siendo manejados por la fuente correcta.

HTTPS (autofirmado): está encriptado, pero una parte confiable no verifica que la fuente correcta lo maneja.

Es por eso que los certificados autofirmados reciben un aviso muy importante. Aunque no significa que el certificado sea inseguro, el navegador no puede confirmar que el certificado es seguro en el uso / transmisión de sus datos. Sin este aviso importante, un estafador / pirata informático podría reemplazar el certificado por uno propio y usted no sabría nada.

La visita a una URL https conlleva una expectativa de seguridad. Visitar una url http no lo hace. Esto se aplica no solo cuando se escriben manualmente las URL, sino quizás más importante cuando se siguen los enlaces y se envían los formularios.

Una solución a esto sería agregar otro esquema de URL para "cifrado pero no autenticado", pero incluso si todos los navegadores comenzaran a admitirlo mañana, tomaría mucho tiempo antes de que fuera lo suficientemente amplio como para que los sitios web confiaran en él. También sería potencialmente difícil explicar las diferencias de seguridad a los usuarios.

Otra solución sería realizar la encerción opertunística bajo el esquema de http url. Una vez más, aunque obtener soporte en los navegadores sería una ardua lucha.