¿Qué debo saber antes de configurar Perfect Forward Secrecy?

PFS en SSL implica que el servidor realiza, para cada nueva sesión, un intercambio de claves Diffie-Hellman y una firma, por lo que el costo de la CPU del protocolo de enlace en el servidor se duplica en comparación con una Suite de cifrado no PFS. Pero es bastante infrecuente que el costo de la CPU del protocolo de enlace no sea despreciable (los clientes que abren varias conexiones utilizan el protocolo de enlace abreviado que solo usa criptografía simétrica, y una PC básica tiene la potencia suficiente para manejar varios cientos de programas por segundo con una sola CPU). núcleo). Sugiero hacer un punto de referencia en contexto.

Aún con SSL, no hay un conjunto de cifrado compatible con PFS que también admita el cifrado RC4. Aparte de eso, todos los navegadores web no arqueológicos actualmente implementados aceptarán las suites de cifrado "DHE" (que producen PFS), por lo que aquí no hay ningún problema de interoperabilidad; la pregunta es más bien si desea RC4 o no: tiene que equilibrar el temor de un compromiso de clave posterior (contra el cual PFS agrega algo de protección) con el temor de los ataques de texto cifrado elegidos (es decir, BEAST, a los que las suites de cifrado RC4 parecen inmunes).

El sistema operativo o el equilibrador de carga podría informar las estadísticas de conjuntos de cifrado, pero no apostaría por ello. Puede realizar pruebas con OpenSSL (el ejecutable de la línea de comandos, con el comando s_client ). También puede usar cualquier analizador de protocolo decente como Wireshark , que puede decirle qué conjunto de cifrado se usa en una conexión determinada (el identificador del conjunto de cifrado se envía "en el claro" como parte de los pasos iniciales del apretón de manos, por lo que es fácil agarrarlo con un rastreador).

La interoperabilidad fue un problema en el pasado, particularmente en ipsec. SSL es un poco más fácil, pero no todos los clientes lo admiten. Si quisiera revisar mi tráfico, probablemente pondría tcpdump en un puerto de tramo y escribiría un script para buscar el paquete de cifrado aceptado en el apretón de manos, asumiendo que estamos hablando de SSL.

  

¿Qué errores o errores comunes debo tener en cuenta antes de implementar esto? ¿Algo administrativo, de implementación específica o de plataforma?   Algunos que vienen a la mente.

Hay dos algoritmos de intercambio de claves utilizados en TLS de secreto de reenvío. DHE y ECDHE. Para avanzar en secreto con la gama más amplia de clientes que necesita para soportar ambos. Por lo general, debería preferir ECDHE sobre DHE porque funciona mejor y es compatible con Java 7 (ver más abajo).

Hacer que el secreto hacia adelante sea obligatorio excluirá Internet Explorer (cualquier versión) en Windows XP. Espero que lo mismo se cumpla con cualquier cosa que use las ventanas integradas en la pila SSL / TLS en XP.

Para DHE debe asegurarse de que utiliza parámetros dh fuertes. Debe usar parámetros dh generados personalizados con al menos 2048 bit prime (la seguridad de un dh prime es comparable a una clave RSA de la misma longitud).

Java 6 y 7 se interrumpen si negocia un conjunto de cifrado DHE y utiliza parámetros DH mayores a 1024 bits. Este es un problema particular de Java 6, ya que no es compatible con ECDHE.

  

Antes de hacer obligatorio el PFS en nuestro servidor, me gustaría tener en cuenta y prepararme para las incompatibilidades.

Una opción podría ser hacer que los conjuntos de cifrados de secreto de reenvío sean preferidos pero no obligatorios y configurar su servidor para registrar qué conjunto de cifrado se usa para cada conexión. Luego puede mirar sus registros y determinar cuántos clientes perdería si exigiera el secreto hacia adelante.

  

¿Hay conceptos erróneos sobre lo que PFS puede y no puede hacer? ¿Podría nuestro departamento de auditoría necesitar una verificación de la realidad?

Básicamente, lo que hace el secreto hacia adelante es evitar que alguien que robó su clave la utilice para descifrar el tráfico de forma pasiva. En particular, sin el secreto hacia adelante, alguien que haya estado monitoreando y almacenando su tráfico y luego robe su clave puede regresar y descifrar el tráfico que capturaron previamente.

Lo que no hará el secreto hacia adelante es evitar que alguien que robó tu llave la use para suplantarte (y actuar como un hombre en el medio o reemplazar tu servidor por el de ellos).

El secreto de reenvío no lo ayudará si se rompe el cifrado simétrico. La criptografía utilizada para el intercambio de claves de secreto hacia adelante también podría romperse (consulte el comentario sobre los parámetros dh anteriores).

  

¿Los beneficios de PFS están limitados por aplicación? (web vs smtp, etc)

Los beneficios son los mismos pero es posible que el soporte en los clientes no sea tan común.