¿Por qué los https autofirmados son menos confiables que los http sin cifrar?

  

Dado que la mayoría del tráfico se intercepta simplemente de forma pasiva, lo que significa que el cifrado sin autenticación le permitirá alejarse de la vigilancia ...

Por lo general, es fácil interceptar el tráfico activamente si está dentro de la misma LAN (W), por ejemplo. Haciendo ARP spoofing o técnicas similares. Y, para las partes que pueden interceptar el tráfico de forma pasiva en Internet, generalmente también es posible cambiarlo o redirigirlo de alguna manera (como con la falsificación de DNS) e incluso hay un ISP que modifica el tráfico para inyectar anuncios, etc. / p>

Ya es difícil para las personas entender la diferencia entre HTTP simple (sin cifrado), HTTPS "simple" y HTTPS "mejor" (por ejemplo, certificados de validación extendidos). Lo que proponen aquí es otro nivel de seguridad, que es un poco mejor que ningún cifrado y mucho peor que el simple HTTPS, porque confiar ciegamente en cualquier certificado de pares que obtenga lo hace abierto a ataques fáciles de intermediarios.

Por supuesto, si solo unas pocas personas usan un servicio determinado, pueden usar certificados autofirmados o técnicas similares. Pero en este caso, debe verificar el certificado o la clave pública fuera de banda, como al obtener la huella digital del certificado o la clave pública de alguna otra manera y compararla con la huella digital presentada por la conexión. Esto funciona si tiene su propio servidor de correo o si hace ssh con los hosts que controla. Pero, como por lo general no tiene una infraestructura establecida y segura para la verificación fuera de banda, esto no funcionará para un público más amplio.

Actualmente, solo tenemos dos protocolos especificados: HTTP simple y HTTPS que requiere certificados válidos. Si simplemente dijéramos que "HTTPS ahora es posible con certificados autofirmados", su navegador no podría distinguir si un sitio que está tratando de visitar tiene un certificado autofirmado porque se supone que lo es, o porque está siendo atacado. Por lo tanto, disminuiría la seguridad.

Podríamos definir un nuevo esquema de URL, por ejemplo, httpe, donde se esperan certificados autofirmados. Requeriría que todos los navegadores lo implementen antes de ser útiles.

Utilizar HTTPS solo como una guía, y simplemente no mostrar el ícono del candado si se encuentran certificados autofirmados, sería extremadamente peligroso: Imagine que su aplicación web envía datos confidenciales a una URL https. No desea que esas solicitudes se realicen si No se puede establecer una conexión segura. Por lo tanto, incluso si quisiéramos, alejarnos de https = tanto encriptado como autenticado no funcionaría.

También podríamos preguntar a los servidores HTTP antes de la solicitud real si admiten el cifrado oportunista, y si dicen que sí, actualicen a TLS mientras aún muestran las URL de HTTP. Algo así se está proponiendo para HTTP 2 aquí y aquí .

En una nota al margen, StartSSL ofrece certificados gratuitos para uso no comercial / no sensible (esta restricción está oculta en su política , sección 3.1.2.1).

De acuerdo con @SteffenUllrich que, por sí solo, existen pocos modelos de amenazas contra los que esto protege. Prácticamente todas las situaciones que se pueden detectar pasivamente también se pueden detectar activamente si se utilizan HTTPS sin confianza. El uso de este esquema con algo como la convergencia de Moxie Marlinspikes ( www.convergence.io ) sería efectivo, por cierto, que intenta reemplazar el modelo de CA actual Con algo más robusto. Eso me haría sentir más cómodo, aunque creo que tiene sus propias fallas (esas fallas se ven empañadas por las de la infraestructura de CA actual, que en su mayor parte es completamente insuficiente).

Y para responder a su pregunta, la autofirmada es MEJOR que HTTP simple, pero las ganancias de seguridad son en realidad muy pequeñas porque no hay forma de verificar la identidad del servidor al que se está conectando el cliente.

Esta es su declaración, los certificados autofirmados de IMO o caducados por CA siguen siendo dignos de confianza que ninguno (HTTP).

El protocolo de seguridad es el más seguro al menos: 1. HSTS 2. HTTPS 3. HTTP

¿Quién firmó su certificado no está relacionado con qué tan seguro es? Todo depende de quién puede descifrarlo.

El cifrado se define por autenticación, no repudio, integridad y confidencialidad.

Cualquier persona puede crear un certificado autofirmado, lo que no garantiza el no repudio (puede ser una identidad falsa).

En teoría, esto es menos confiable que un certificado firmado. Los certificados de CA (firmados) son más seguros en teoría, pero se pueden eludir fácilmente: c.f. SSLStrip o SSLSnif enlace

HTTP (S) es un protocolo sin estado, puede manipular los marcos POST, GET, PUT y también crear cookies. HTTPS ofrece cifrado, mientras que HTTP no lo hace, cuando se trata de transmitir información crítica independientemente del certificado (CA firmado, caducado, autofirmado) sigue siendo preferible que ningún cifrado.

Aquí hay una alternativa en la que puede estar interesado: enlace