Versiones y suites aceptables

Al abrir una conexión, el cliente ofrece las versiones y las suites que sabe usar, y el servidor escoge una. La suite es el paquete de algoritmos: cómo se acuerda la clave, cómo se cifra y cómo se comprueba la integridad. Una versión antigua o una suite débil convierte un certificado perfecto en un cifrado mediocre.

Las versiones 1.0 y 1.1 de TLS fueron retiradas formalmente por el IETF en el RFC 8996, y SSL 3.0 lleva años prohibido. Para TLS 1.2 conviene fijar qué se acepta: las suites con intercambio de claves efímero y cifrado autenticado son las que se buscan. Las que usan RSA estático para acordar la clave no dan secreto perfecto hacia adelante: quien capture hoy el tráfico y consiga después la clave del servidor puede descifrar todo lo capturado. TLS 1.3 eliminó ese intercambio.

La política de la empresa fija una versión mínima. Lo que se mide en la revisión es lo que cada servicio acepta, no lo que usa la mayoría de sus clientes: basta con que un servicio acepte una versión antigua para que un intermediario pueda forzar la negociación hacia ella si el cliente también la tolera.

Consulta la tabla revision y mira la columna versiones_aceptadas contra la política.

Aceptar solo TLS 1.2 no basta. Dentro de TLS 1.2 conviven suites excelentes y suites que la política prohíbe. En la revisión la señal es doble: la columna suite_no_aceptable nombra una suite ofrecida y la columna secreto_perfecto dice si hay secreto perfecto hacia adelante.

Cruza ambas columnas con la de versiones: busca el servicio que cumple la versión mínima pero ofrece una suite sin secreto perfecto.

La política es la regla y la revisión es la medida. Un servicio incumple si acepta alguna versión por debajo de la mínima o si ofrece alguna suite de las que la política no admite; con una de las dos basta. Contar cuántos incumplen, y cuáles, es la cifra con la que se prioriza el trabajo.

Lee la política, revisa las seis filas de revision una por una y cuenta los servicios que incumplen por cualquiera de los dos motivos.

No todo se puede subir de versión. La tabla observaciones muestra un equipo de bodega con un firmware que ya no recibe actualizaciones y un contrato que impide tocar la aplicación de un proveedor. La salida cómoda es bajar la exigencia para todos; la ordenada es contener el riesgo donde está y dejar la excepción escrita, con dueño y fecha para revisarla.