¿Qué sucede en el cable cuando una conexión TLS / LDAP o TLS / HTTP está configurada?

Estoy reformulando mi pregunta, así que espero poder obtener una mejor respuesta. Hice una pregunta similar sobre la falla del servidor aquí , y creo que un servidor TLS correcto y válido es aquel que espera el comando “STARTTLS”.

¿Es cierto que STARTTLS se puede emitir a un servidor LDAP o HTTP TLS configurado correctamente sin necesidad de un puerto adicional? Sé que esto es cierto desde una perspectiva de SMTP, pero no estoy seguro de cuán ampliamente puedo aplicar esas experiencias a otros protocolos.

He pasado tiempo leyendo (pero no entendiendo por completo)

  • La especificación TLS
  • Diferencias entre TLS y SSL
  • La especificación SSL

P: ¿Qué sucede en el cable justo antes de que se configure la sesión de TLS sobre LDAP o HTTP? Como esto se basa en TCP, ¿puedo simplemente hacer telnet en ese puerto y emitir algún comando para verificar que esté funcionando (hasta ese momento)?

Hay muy pocas diferencias entre SSL y TLS en la forma en que se usan. Sin embargo, existe una diferencia fundamental entre el establecimiento inicial de SSL / TLS y el uso de un comando como STARTTLS . A veces, “TLS” se usa en contraste con “SSL”, para decir “usando un modo STARTTLS” pero esto es incorrecto.

Up-front TLS / SSL

En este caso, el cliente inicia la conexión TLS / SSL antes que nada, por lo que el protocolo de enlace SSL / TLS pasa primero. Una vez que el socket seguro está activo, la aplicación que lo usa puede comenzar a enviar los diversos comandos para el protocolo por encima de TLS (por ejemplo, HTTP, LDAP en este modo, SMTP).

En este modo, las versiones de SSL / TLS deben ejecutarse en un puerto diferente de sus contrapartes simples, por ejemplo: HTTPS en el puerto 443, LDAPS en el puerto 636, IMAPS en el puerto 993, en lugar de 80, 389, 143, respectivamente.

Las capas que implementan estos protocolos de aplicación apenas necesitan saber que se están ejecutando sobre TLS / SSL. A veces, simplemente se tunelizan en herramientas como sslwrap .

TLS después de STARTTLS (o equivalente)

La especificación TLS permite el intercambio de información en cualquier momento, incluso después de haber intercambiado algunos datos en TCP simple a través de la misma conexión TCP.

Algunos protocolos, incluido LDAP, incorporan un comando para indicar al protocolo de la aplicación que habrá una actualización. Esencialmente, la primera parte de la comunicación LDAP ocurre en texto plano, luego se envía un mensaje STARTTLS (todavía en texto plano), lo que indica que la conexión TCP actual se reutilizará pero que los siguientes comandos se envolverán dentro de un TLS / SSL capa. En esta etapa, se produce el protocolo de enlace TLS / SSL y la comunicación se “actualiza” a TLS / SSL. Solo después de esto la comunicación se asegura a través de TLS / SSL, y tanto el cliente como los servidores saben que deben envolver / desenvolver sus comandos de la capa TLS (normalmente agregando una biblioteca TLS entre la capa TCP y la capa de la aplicación).

Los detalles de cómo se implementa STARTTLS dentro de cada protocolo varían dependiendo del protocolo (porque esto tiene que ser compatible con el protocolo que lo usa hasta cierto punto).

Incluso HTTP tiene una variante que utiliza este mecanismo, aunque en su mayoría nunca se admite: RFC 2817 Actualización a TLS dentro de HTTP / 1.1 . Esto es completamente diferente de la forma en que funciona HTTPS ( RFC 2818 ), que inicia primero TLS / SSL.

Las ventajas del enfoque STARTTLS es que puede ejecutar tanto variantes seguras como simples en el mismo puerto, las desventajas son las consecuencias de eso, en particular los posibles ataques de degradación o posibles errores en la configuración.

( EDITAR : he eliminado una oración incorrecta, como señaló @GregS, gracias).

( EDITAR : También he puesto más en SSL vs. TLS en esta respuesta en ServerFault ).

El “comando STARTTLS” es algo que está definido fuera de la especificación TLS. Es lo que un cliente envía a un servidor en una conexión previamente descifrada para decir “Ok, comencemos una negociación de TLS ahora”.

No todos los protocolos implementan dicho comando. SMTP sí, pero HTTP y LDAP (hasta donde yo sé) no lo hacen.

Cuando un comando explícito para comenzar TLS no está presente, la alternativa habitual es designar un puerto específico: como 443 para HTTP (s) y 636 para LDAP (s). En ese caso, la negociación de TLS comienza tan pronto como se establece la conexión TCP.

Una buena herramienta para solucionar problemas que es la herramienta “s_client” en openssl. Por ejemplo:

 openssl s_client -connect ldap.mycompany.com:636 

conectará y descargará el certificado del servidor. Piense que es como “Telnet” para una conexión TLS. (Por supuesto, LDAP no es un protocolo basado en texto, por lo que no se puede hacer nada útil desde el teclado una vez que se establece la conexión TLS).

LDAP utiliza una operación extendida para iniciar la instalación de la capa TLS. Ver también la sección 4.14 en el RFC .