Si veo un sitio que tiene un certificado SSL sin firmar o autofirmado, mi navegador me avisa. Sin embargo, el mismo navegador no tiene problemas para permitir el envío de credenciales a través de páginas no seguras.
¿Por qué el certificado autofirmado se trata peor que no tener certificado?
Respuestas:
Hay muchas personas que sienten que este sistema está roto.
Aquí está la lógica detrás de por qué su navegador le dará una advertencia tan alarmante cuando un certificado SSL no es válido:
Uno de los propósitos de diseño originales de la infraestructura SSL era proporcionar autenticación de servidores web. Básicamente, si visita www.bank.com, SSL permite que el servidor web que responde demuestre que, de hecho, pertenece a su banco. Esto evita que un impostor manipule DNS o use otro método para que un servidor malicioso responda.
La "confianza" en SSL se proporciona al tener un tercero de confianza (compañías como VeriSign y Thawte Consulting) que firman el certificado, lo que indica que han verificado que es propiedad de quien dice ser (en teoría visitando al administrador de TI en persona u otro método que crea confianza directa, aunque la evidencia muestra que en realidad son bastante laxos al respecto; todo lo que se necesita para obtener un certificado SSL firmado es a menudo un número 800 y un poco de habilidad para actuar).
Entonces, si se conecta a un servidor web que proporciona un certificado SSL, pero no está firmado por un tercero confiable, en teoría esto podría significar que se está comunicando con un impostor que finge ser un servidor que pertenece a una organización diferente .
En la práctica, un certificado autofirmado generalmente significa que la organización que ejecuta el servidor decidió no pagar por un certificado firmado (pueden ser bastante caros, dependiendo de las características que desee), o carecía de la experiencia técnica para configurar uno ( Algunas soluciones para pequeñas empresas ofrecen un mecanismo de un solo clic para un certificado autofirmado, pero obtener un certificado de confianza requiere más pasos técnicos).
Personalmente, creo que este sistema está roto y que comunicarse con un servidor que no ofrece cifrado es mucho más peligroso que comunicarse con un servidor que ofrece SSL con un certificado autofirmado. Hay tres razones por las que los navegadores no actúan así:
El envío de credenciales de una página a otra es básicamente hacer HTTP POST. No hay nada especial en el envío de credenciales en comparación con el envío, por ejemplo, términos de búsqueda a través de POST. Si cualquier publicación en una página no segura desencadenaría una advertencia, los usuarios serían bombardeados por advertencias sin sentido.
El uso de un canal seguro indica la intención del programador de asegurar la transferencia. En este caso, usar la advertencia de certificado autofirmado es algo muy correcto.
No puedo comentar, así que publicaré esta información que complementa la información correcta del usuario40350.
Sin embargo, el mismo navegador no tiene problemas para permitir el envío de credenciales a través de páginas no seguras.
Eso en realidad ni siquiera es cierto. La mayoría de los navegadores mostrarán una advertencia como si estuvieras a punto de enviar datos a través de una conexión no segura cuando lo intentas por primera vez, pero puedes desactivarlo para que nunca vuelva a aparecer, y apuesto a que eso es exactamente lo que has hecho ...
Miro A escribió:
El envío de credenciales de una página a otra es básicamente hacer HTTP POST. No hay nada especial en el envío de credenciales en comparación con el envío, por ejemplo, términos de búsqueda a través de POST
Esto también es incorrecto, ya que los campos de contraseña son etiquetas html especiales, por ejemplo. Además de eso, las etiquetas como "nombre de usuario" y "contraseña" también traicionan mucha de su sensibilidad. Sería perfectamente factible para los navegadores tener en cuenta este tipo de información.
El navegador indica que las conexiones que están protegidas por el protocolo https: // están "aseguradas". Por ejemplo, se muestra un pequeño candado o partes de la URL están marcadas en verde.
Por lo tanto, se supone que el usuario debe confiar en que las páginas que está visitando provienen de la URL que ingresó y no son de otra persona.
Si no usa https: //, se supone que el usuario debe saber que los datos ingresados no están protegidos y que el sitio en el que está navegando podría estar impuesto.
Un certificado autofirmado no garantiza que, una vez más, se espera que la página navegada no se imponga, por lo tanto, no ofrece seguridad adicional.
Se debe hacer una distinción entre un certificado de confianza (firmado por una autoridad de confianza) y no confiable. De lo contrario, alguien podría hacerse pasar por su banco (por ejemplo) mediante el uso de un certificado autofirmado con relativa impunidad.
Una advertencia directa es preferible a una sutil en este caso porque el riesgo potencial es relativamente alto. Las personas pueden hacer clic en un enlace https y ni siquiera pensar que alguien podría estar sentado en el medio monitoreando la conexión. Si la indicación de que el certificado no es de confianza es sutil (digamos un icono rojo en lugar de verde, etc.), las personas podrían ser engañadas fácilmente, eliminando los beneficios de SSL.
Se han enumerado muchas buenas razones. Aquí hay uno más:
Piense en casos en los que una página web segura incorpora elementos de otra. Un atacante podría detectar qué solicitudes son para la página web externa (por ejemplo, al observar el tiempo, tiene que venir primero) y cuáles son para los elementos internos. Podría inyectarse como MITM solo en los elementos internos, usar un certificado autofirmado y controlar partes de la página. A menos que se presente una advertencia para los elementos internos que usan SSL pero no usan un certificado confiable, la seguridad de la página externa se vería comprometida.
Aquí hay un ejemplo realista. Digamos que soy un proveedor y tengo un enlace de "pagar con PayPal". Haces clic en eso, y lo sé. Lo redirijo a PayPal y le dejo obtener la página de PayPal legítima y segura. Si estoy viendo tu red, sé que será tu primera solicitud de PayPal, y poco después enviarás tu contraseña. Así que MITM submitcontiene su dirección de correo electrónico y contraseña, sustituyendo mi certificado autofirmado por el de PayPal.
¿Ves cómo la seguridad de la página externa se ve comprometida al no advertir si el certificado de la página interna está autofirmado? Por lo tanto, debe advertir sobre los certificados autofirmados que provienen de los enlaces.
Y, por supuesto, si ingresa httpsmanualmente, debe advertirle. Porque esperas que sea seguro.
Cuando el ataque man in the middle se ejecuta en https: // sitio web, la advertencia es solo una indicación de algo incorrecto para el usuario promedio. Por lo tanto, es una parte muy importante de la seguridad HTTPS.
La buena pregunta es por qué el cifrado parcialmente inseguro no es posible, por ejemplo, a través de HTTP.