¿Por qué no hay más sitios web que implementen Perfect Forward Secrecy?

En realidad, la mayoría de los sitios web do implementan secreto de envío , es decir, al menos uno de los " DHE "(o" ECDHE ") conjuntos de cifrado. La mayoría de las implementaciones de SSL las admiten fuera de la caja, y la mayoría de los certificados de servidor SSL son adecuados (con un conjunto de cifrado DHE, la clave del servidor se usa para una firma ; pero casi todo el mundo usa RSA y casi todos los certificados de RSA permitir el uso de claves para firmas).

Sin embargo, la mayoría de las implementaciones de SSL también son corteses , ya que el servidor sigue las preferencias del cliente. Esto significa que, en la lista de suites de cifrado anunciadas como compatibles con el cliente (en el mensaje ClientHello ), el servidor usualmente seleccionará el primero que también es compatible en el lado del servidor. Como la mayoría de los clientes tienden a poner en primer lugar las suites de cifrado que no son de DHE, las suites de DHE no se utilizan.

El costo adicional incurrido por las suites de cifrado DHE es leve y casi siempre insignificante:

• El costo computacional para el apretón de manos se ha duplicado. Esto significa que un servidor básico puede realizar "solo" 1000 protocolos completos por segundo en lugar de 3000, según la CPU disponible. Dado que los servidores no suelen presumir 1000 nuevos clientes por segundo, en una sola PC, esta limitación nunca es una verdadera limitación en la práctica.

• El ancho de banda adicional es pequeño: menos de 1 kilobyte de sobrecarga inducida por el uso de un conjunto de cifrado DHE. Una vez más, esta sobrecarga es solo para un apretón de manos completo, es decir, la primera conexión entre un cliente y un servidor; las conexiones posteriores utilizarán el "apretón de manos abreviado", que es más eficiente y no se ve afectado por el conjunto de cifrado real.

Por lo tanto, para resumir, el secreto hacia adelante ya está ya y está infrautilizado solo debido al comportamiento tradicional de los clientes y servidores (orden de preferencia), que permanece sin ser una buena razón técnica. solo inercia . En algunos casos, los desarrolladores o administradores de sistemas desactivan el soporte de DHE en función de algún rumor no confirmado acerca de cómo el DHE es "muy caro" y "podría afectar en gran medida el rendimiento", pero estos mitos se pueden disipar fácilmente con algunos puntos de referencia reales y aún son poco frecuentes. Los navegadores y servidores eligen conjuntos de cifrado que no son de DHE, principalmente porque ese es el comportamiento predeterminado y nadie se siente lo suficientemente motivado para hacer nada al respecto.

Para completar, hay un efecto adicional: cuando se publicó el ataque BESTIA, la gente se entristeció y el mantra común fue: "usar RC4, es inmune". SSL no tiene ningún conjunto de cifrado DHE con RC4 (no hay incompatibilidad entre DH y RC4, pero simplemente sucede que no se ha definido dicho conjunto de cifrado estándar). Por lo tanto, los clientes y servidores prefirieron las suites de cifrado RC4, lo que indirectamente implica que no utiliza las suites de cifrado DHE.

El protocolo de enlace de DHE es muy costoso y, por lo tanto, podría tener un gran impacto en el rendimiento del servidor. ECDHE es mucho mejor (solo un 15% de sobrecarga con implementaciones optimizadas) pero necesita una biblioteca que lo admita. OpenSSL, por ej. la biblioteca que está detrás de la mayoría de los servidores web basados en UNIX, agregó soporte con 1.0.1 - y sí, esta es exactamente la versión que agregó la extensión de latido que permitió el famoso ataque de corazón. Por lo tanto, si su servidor requiere OpenSSL y desea utilizar un PFS efectivo y ser inmune a este ataque severo, tiene que usar una versión de OpenSSL de algunos días o parchear su versión.

Al final, podría haber sido bueno que muchos sitios web fueran demasiado vagos para agregar PFS :)

Estas son algunas de las razones por las que los sitios no implementan el secreto hacia adelante (también llamado Perfect Forward Secrecy o PFS).

Por definición, solo el servidor que termina con TLS y el cliente pueden descifrar la carga útil real. Esto significa que otros procesos, que pueden tener una razón legítima para descifrar el texto cifrado, están bloqueados fuera de la conversación. Hay muchas razones legítimas para hacer esto, y aquí hay algunos ejemplos.

• PFS interrumpirá un sistema de monitoreo de disponibilidad que recibe periódicamente el tráfico, lo descifra, comprueba los códigos de estado y luego marca la red como "arriba" o "abajo". He visto a centros de datos enteros apagarse debido a esto.
• Las herramientas de diagnóstico, como 'ssldump' ya no funcionan con PFS. Supongamos que un cliente final dice "Ingreso mi nombre de usuario y contraseña, y el sistema dice que estoy conectado, pero no lo estoy. ¿Qué está pasando?" Con PFS, el administrador no puede capturar una conexión específica y luego descifrarla para ver el HTML en su interior.
• Los aceleradores de WAN obtienen cada clave de sesión y luego realizan la desduplicación de datos para toda una oficina en configuraciones de radio y concentrador. Los aceleradores WAN mejoraron el rendimiento y redujeron el ancho de banda. Imagine a 50 personas en una oficina del campus conectándose a la sede para descargar el mismo archivo PDF de 5Mb (por ejemplo, una nueva lista de precios). La eliminación de la duplicación significó que el PDF se transfirió desde la oficina en el hogar exactamente UNA VEZ, y todos los demás que accedan desde el sitio del campus recibirían silenciosamente la copia local almacenada en caché por el acelerador de la WAN. PFS rompe eso, y ahora el PDF se debe transferir 50 veces.

• Los sistemas de alta disponibilidad (HA) que comparten claves SSL pueden ser interrumpidos por PFS. Supongamos que está descargando un archivo ISO de gigabyte a través de una conexión TLS lenta y el servidor TLS se apaga repentinamente. En un sistema de alta disponibilidad, otro servidor TLS puede calcular la clave de la sesión y puede "capturar" la conexión de forma silenciosa y mantener la descarga. PFS puede romper sistemas de HA más antiguos. Nota: los sitios de HA SSL son bastante raros, pero están disponibles.

  He visto todos los ejemplos con clientes. Sí, hay formas de evitar cada uno de ellos, pero todos implican trabajo adicional.

Cuando un administrador del sitio o un proveedor de TLS está tratando de priorizar arreglos y características, pueden decidir que el beneficio promocionado del secreto hacia adelante (evitar que los estados nacionales espíen) no justifica los cambios de red o el aumento de ancho de banda en este momento.

Dicho esto, si se mide por las direcciones IP (y no por el rango de alexa), la mayor parte de Internet (50% +) es compatible con TLS porque son servidores simples de una caja que no tienen estos requisitos más complicados.