¿Debo usar la renegociación SSL / TLS?

El problema no está en hacer una renegociación; Es en la creencia en las características de seguridad que la renegociación no proporciona no .

La renegociación es hacer un nuevo saludo en medio de una conexión SSL / TLS. Esto se describe en el estándar , aunque no en términos muy claros, especialmente cuando se trata de definir qué garantías ofrece la renegociación.

La renegociación es muy común cuando se usa con certificados de cliente, especialmente con IIS. Las cosas van así:

• El servidor recibe una solicitud de conexión en el puerto 443; comienza un apretón de manos. El servidor no solicita un certificado de cliente.
• Una vez que se completa el protocolo de enlace, el cliente envía la URL de destino real como una solicitud HTTP en el túnel SSL. Hasta ese momento, el servidor no sabía a qué página estaba dirigida; solo sabía, en el mejor de los casos, el servidor deseado nombre (a través de la Indicación del nombre del servidor ) Ahora que el servidor sabe a qué página está dirigida, él sabe qué "sitio" (es decir, parte del servidor, en la terminología de IIS) debe usarse.
• Si el sitio específico requiere o al menos exige autenticación de cliente basada en certificados, el servidor genera un nuevo protocolo de enlace, esta vez con un mensaje CertificateRequest .

El problema de seguridad aquí es una cuestión de capas. Los mensajes de intercambio aparecen "bajo la cubierta" como interacciones administrativas fuera de banda administrativas, alrededor del tráfico principal de "datos de aplicación", que es solo HTTP. Una vez que se haya realizado el nuevo protocolo de enlace, los datos de la aplicación enviados posteriormente están cubiertos por el paraguas de autenticación de SSL. Sin embargo, ¿qué pasa con los datos de la aplicación que se enviaron antes del segundo protocolo de enlace, en particular la solicitud HTTP inicial que decidió que el servidor realizara un segundo protocolo de enlace o, de manera crucial, otras solicitudes HTTP canalizadas después de este (pero antes del nuevo apretón de manos)?

Sucede que los servidores web solían asumir que la autenticación que se acaba de realizar en el segundo saludo se podría "transportar" a los datos anteriores, de manera retroactiva. Sucede que no es cierto. Eso nunca se ha dicho claramente en el estándar SSL / TLS, pero tal autenticación solo actúa de manera directa: no hay viajes en el tiempo. La palabra importante en el párrafo anterior es "posteriormente". Esto permitió un ataque real (consulte esta página para obtener sugerencias de explicaciones exhaustivas).

Un punto crucial para el ataque práctico es que los mensajes del segundo saludo no se pueden distinguir de los mensajes del saludo para una nueva conexión (es decir, un "primer saludo"). RFC 5746 describe el parche, que se ha implementado en los principales navegadores y servidores (que asumimos que está actualizado con arreglos de seguridad, de lo contrario, de todas formas, estás en un gran problema Esto es también lo que OpenSSL informa como "Renegociación segura". Tenga en cuenta que el RFC dice con franqueza que:

  

Si bien esta extensión mitiga el ataque del hombre en el medio descrito      en el resumen, no resuelve todos los problemas posibles y      la aplicación puede enfrentar si desconoce la renegociación.

En otros términos, este es un parche para solucionar un problema demostrado, pero no pretende cubrir todos los motivos. Lo que ofrece la renegociación realmente todavía no está claramente definido en ninguna parte. Si sus clientes y su servidor admiten "Renegociación segura", entonces las cosas están bien por ahora (previene todos los ataques conocidos actualmente ). Todo el concepto de renegociación y apretones de manos intercalados todavía necesita un análisis más formal.

Durante la renegociación, un atacante puede inyectar información en la conexión. Se describe en detalle aquí .