¿Cómo puedo habilitar el cifrado oportunista para mi sitio web?

5

Según una mención honorífica en una respuesta para « ¿Por qué los https autofirmados son menos confiables que los http no encriptados? », parece que ya hay dos borradores posteriores a Snowden que tienen que ver con el tema exacto del cifrado oportunista del tráfico http:

  • Cifrado oportunista para URI de HTTP
    enlace

  • Cifrado no autenticado mínimo (MUE) para HTTP / 2
    enlace

Están un poco tensos en los detalles; Además, al ser documentos de referencia, obviamente no hablan de detalles de implementación y soporte de productos.

Pero estoy realmente emocionado de que alguien finalmente esté trabajando para hacer posible el cifrado oportunista de HTTP, como hemos tenido STARTTLS en SMTP durante años. ¿Se ha implementado algo de esto? Realmente me gustaría habilitar todo esto en todos mis sitios web sin fines de lucro, ¿alguna forma de ser un adoptador temprano?

    
pregunta cnst 30.06.2014 - 02:55
fuente

2 respuestas

2

Ninguno de los agentes de usuario principales (IE, FF, Chrome, etc.) apoya cualquiera de esas propuestas, por lo que actualmente no hay manera de hacer HTTPS oportunistas. ¿Por qué no solo sirve todo su contenido a través de HTTPS para todos? Parece que esa es la mejor manera de ofrecer a sus usuarios confidencialidad e integridad.

    
respondido por el David 21.07.2014 - 01:53
fuente
0

Creo que mezcla el cifrado oportunista como se describe en estos borradores y STARTTLS.

STARTTLS tiene una semántica claramente definida sobre cómo deben verificarse los certificados (ver RFC6125) y la mayoría de los Agentes de Usuarios de Correo (MUA) implementan estas validaciones al conectarse a un Agente de Transporte de Correo (MTA). Por lo tanto, debe aceptar explícitamente una huella digital específica de un servidor si el certificado está firmado por una CA desconocida. La mayoría de los MTA ofrecen formas de deshabilitar estas comprobaciones de validación, con la argumentación de que el TLS no validado ayuda contra el monitoreo pasivo, por lo tanto es mejor que ningún TLS.

Pero, el modelo de seguridad del correo (SMTP) es totalmente diferente del HTTP. SMTP es un protocolo de salto por salto con al menos en MTA entre la MUA de origen y destino. No hay cifrado de extremo a extremo (es decir, de MUA a MUA), sino solo salto por salto. Esto significa que cualquier MTA intermedio puede ver y modificar los correos electrónicos en texto sin formato, incluso si la conexión a este MTA está protegida por TLS. Entonces, si necesita privacidad con SMTP, necesita cifrar el cuerpo del correo usted mismo: para eso están PGP y S / MIME.

En su lugar, HTTP proporciona una conexión de extremo a extremo entre las partes y HTTPS, por lo que ofrece un cifrado de extremo a extremo. No hay una capa de seguridad adicional definida (por ejemplo, similar a PGP o S / MIME), por lo que su privacidad depende únicamente de la implementación adecuada de TLS.

Eche un vistazo a la sección sobre consideraciones de seguridad en los RFC a los que hizo referencia. Ambos afirman claramente que solo protegen contra el monitoreo pasivo, que son vulnerables a los ataques de intermediarios y que los creadores de navegadores no deben proporcionar una interfaz de usuario que pueda sugerir una protección comparable a HTTPS.

Y sobre sus quejas sobre el "cartel" asociado con HTTPS: No hay nada inherente con TLS / HTTPS que necesite tal "cartel". Pero, lo que necesita es una forma de validar la identificación (certificado) presentada por el par, ya que de lo contrario sería vulnerable a los ataques del hombre en el medio (activo). Históricamente, esta validación se ha implementado al tener un conjunto fijo de anclas de confianza en los navegadores y comenzar desde allí para validar el certificado. Si tiene otra forma confiable de verificar el certificado de servidores, puede usarlo, pero al final no elimina la necesidad de algún tipo de anclajes de confianza, sino que solo lo reemplaza con otros anclajes de confianza. Al igual que con DANE, donde necesita DNSSec que nuevamente necesita CA confiables para firmar las entradas de la raíz del DNS y construir una cadena de confianza desde allí para verificar las entradas del DNS que incluyen el certificado.

No sugeriría, que la forma actual con 100s de CA de raíz totalmente confiables dentro del navegador es la forma en que debemos continuar. Pero al menos proporciona la seguridad esperada en la mayoría de los casos. Por lo tanto, no recomendaría reemplazarlo por algo mucho peor, es decir, uno de estos borradores que proporciona cifrado sin identificación del par. Ni siquiera recomendaría implementar esto como una opción dentro del navegador, porque el usuario promedio no podrá entender las diferencias entre los distintos niveles de seguridad.

    
respondido por el Steffen Ullrich 21.07.2014 - 06:29
fuente

Lea otras preguntas en las etiquetas