La respuesta literal es no: TLS no acepta mensajes sin cifrar. Sin embargo, las preocupaciones de su colega no son infundadas. No sé si está confundido pero accidentalmente tropezó con una verdadera preocupación, o si entiende los problemas pero los explica de manera muy confusa.
Una conexión TLS siempre está encriptada (por lo que un hombre en el medio no puede leer los datos que se transmiten) y está protegida por integridad (por lo que un hombre en el medio no puede modificar los datos que se transmiten¹). Aunque la especificación TLS define un conjunto de cifrado "nulo", la mayoría de las aplicaciones no lo utilizarán, y no todas las bibliotecas TLS lo permiten. A menos que haga todo lo posible para habilitarlo tanto en el lado del cliente como en el del servidor, el conjunto de cifrado nulo no ocurrirá. Cada otro conjunto de cifrado tiene cifrado y protección de integridad.
La seguridad de TLS también se basa en que las dos partes se aseguren de que están hablando directamente entre sí. No habría seguridad si todo lo que sucediera es que el cliente legítimo tiene una conexión segura con el intermediario, y el intermediario tiene una conexión segura con el servidor legítimo. La forma en que funciona en la web (y en la mayoría de los demás usos de TLS) es que el cliente autentica el servidor al verificar que el certificado del servidor es válido. No voy a entrar en lo que significa "válido" aquí; en pocas palabras, el certificado debe ser criptográficamente consistente con la conexión (el cliente siempre lo verificará) y debe estar firmado por una autoridad de certificación en la que el cliente confía (este bit es un poco más frágil, pero funcionará si se proporciona utiliza un software razonablemente actualizado y configura el servidor correctamente).
Como de costumbre, todo esto está sujeto a mantenerse al día con las actualizaciones de seguridad en el software y a configurarlo correctamente. Algunas versiones anteriores del protocolo se han roto, es decir, no ofrecen las garantías para las que fueron diseñados. Pero mientras no ejecute software antiguo o habilite funciones obsoletas en la configuración del servidor, todo estará bien.
Entonces, ¿a qué se refiere tu colega?
alguien, algún día, se olvidará de cifrar un mensaje, expondrá su token de sesión / identidad de usuario / lo que sea, y se dejará abierto a un ataque de hombre en el medio
Esto puede suceder incluso si su servidor admite TLS. Un cliente podría enviar una solicitud HTTP en lugar de HTTPS. Luego, un atacante podría hacerse pasar por su servidor y ver los datos que el cliente envió a través de HTTP. No hay nada que el servidor pueda hacer para evitarlo por completo, pero hay cosas que puede hacer para que sea un problema discutible.
Lo primero que hay que hacer es dar solo las URL de las personas que comienzan con https:// . Eso no ayuda si la gente escribe la URL directamente.
Un lado de la moneda es configurar su servidor para que no responda a HTTP, excepto para redirigir al sitio HTTPS. En otras palabras, todo lo que sirve en el puerto 80 son redirecciones a https://same remainder of the URL . Además, comunique al cliente que debe usar HTTPS directamente la próxima vez, habilitando HSTS en la configuración de su servidor. HSTS hace que el servidor envíe al cliente una instrucción para usar siempre HTTPS para un sitio en particular en el futuro. De esta manera, solo la primera conexión de un cliente en particular podría estar en texto sin cifrar.
El otro lado de la moneda es proteger los datos confidenciales para que no se envíen a través de HTTP. No puede proteger las credenciales de los usuarios si insisten en enviarlos en texto claro, al igual que no puede evitar que un usuario abra su ventana y grite su contraseña a todos en la calle. Pero puede proteger las cookies que utiliza su aplicación: asegúrese de que todas sus cookies tienen la marca secure . De esa manera, si el usuario consigue que su navegador realice una conexión HTTP, el navegador no enviará las cookies.
¹ Excepción: un mitm puede forzar el cierre de la conexión a medio camino. En principio, esto es visible porque ocurre a nivel de TCP y ambas partes pueden decir que el nivel TLS no se terminó correctamente (por una alerta fatal), pero las aplicaciones como los navegadores generalmente no proporcionan ningún comentario al respecto, y es indistinguible de fallos de red que ocurren.