Cómo establece TLS una conexión web segura y qué comprueba el navegador

Cuando abres una página HTTPS, el navegador y el servidor necesitan acordar cómo proteger la comunicación antes de intercambiar los datos de la aplicación. Esa negociación inicial se conoce como handshake o establecimiento TLS. No es una contraseña que el usuario escriba: es un intercambio automático de mensajes y parámetros criptográficos.

TLS protege los datos en tránsito mediante confidencialidad e integridad, y permite autenticar al servidor. El resultado práctico es un canal en el que un observador de la red no debería poder leer ni modificar silenciosamente el tráfico. TLS no cifra por sí mismo la información que queda almacenada en los dispositivos o servidores, ni decide si el contenido del sitio es honesto.

SSL es el nombre del protocolo predecesor, ya obsoleto; en las conexiones web actuales, el protocolo pertinente es TLS. Por costumbre aún se habla de “certificados SSL”, pero el certificado es una credencial digital y TLS es el protocolo que establece y protege la conexión. Certificado y protocolo son piezas distintas: tener uno instalado no basta para demostrar que la configuración TLS está bien hecha.

En el inicio, el cliente envía un mensaje ClientHello con información sobre las opciones que admite, como versiones de TLS, algoritmos y datos para el intercambio de claves. El servidor responde seleccionando parámetros compatibles. No se escoge cualquier combinación: ambos extremos deben coincidir en las opciones permitidas por sus implementaciones y configuraciones.

En TLS 1.3, el cliente puede incluir desde el primer mensaje una parte pública del intercambio efímero de claves. El servidor selecciona los parámetros, presenta su certificado y envía su parte correspondiente; ambos extremos derivan de forma independiente secretos compartidos y claves de tráfico. Con ECDHE —Diffie-Hellman efímero sobre curvas elípticas— no se transmite la clave secreta de sesión como un dato que un tercero pueda copiar: se intercambian valores públicos que permiten calcular el secreto en ambos lados.

El cifrado simétrico protege el tráfico posterior porque es más adecuado para procesar grandes cantidades de datos que las operaciones de clave pública. TLS deriva claves de tráfico para proteger los registros de la conexión; no conviene describir el proceso como si el navegador simplemente creara una clave de sesión y se la entregara al servidor. El diseño exacto depende de la versión negociada y de los parámetros acordados.

TLS 1.3 redujo el establecimiento ordinario a un viaje de ida y vuelta de red (1-RTT), mientras TLS 1.2 suele necesitar dos antes de empezar el intercambio normal de datos protegidos. La reanudación de sesión con 0-RTT es una opción distinta: puede permitir enviar datos antes de completar un nuevo viaje de ida y vuelta, pero tiene riesgos de repetición y no es apropiada indiscriminadamente para operaciones que no toleran duplicados. Menos latencia no significa que todas las peticiones sean seguras para 0-RTT.

El certificado del servidor vincula una identidad —normalmente un nombre de dominio— con una clave pública y contiene una firma verificable dentro de una cadena de confianza. El cliente comprueba que la cadena llega a una autoridad raíz que reconoce, que el certificado está dentro de su período de validez y que el nombre solicitado coincide con los nombres cubiertos por el certificado, habitualmente en el campo SAN (Subject Alternative Name).

La validación no consiste solo en mirar si hay un candado. El navegador realiza comprobaciones automáticas y puede rechazar la conexión si el certificado está vencido, el nombre no coincide o la cadena no se puede validar. La comprobación de revocación depende también de mecanismos y políticas del cliente; no debe suponerse que una inspección visual del icono expone todos los detalles de ese proceso.

Un certificado válido autentica el control de un dominio según las reglas de emisión aplicables; no certifica que el negocio sea legítimo, que el sitio no sea fraudulento o que el contenido sea fiable. Un sitio engañoso también puede servir HTTPS para su propio dominio. El candado indica una conexión protegida con ese servidor, no una aprobación de sus prácticas o afirmaciones.

La autenticación TLS web habitual verifica principalmente al servidor. La autenticación mutua, o mTLS, es una configuración adicional en la que el cliente también presenta un certificado para autenticarse. No debe confundirse con el funcionamiento normal de HTTPS, en el que el usuario no entrega necesariamente un certificado personal.

Durante una conexión TLS, el cifrado dificulta que terceros en la ruta lean el contenido protegido y la integridad permite detectar modificaciones de los datos en tránsito. La autenticación del servidor ayuda a reducir el riesgo de que el cliente establezca la conexión con un impostor que no controla la identidad certificada. Estas protecciones se aplican al trayecto de la conexión, no a todos los puntos por los que pasan los datos.

TLS no oculta necesariamente toda la información de contexto. Por ejemplo, la dirección IP del servidor y otros metadatos de red pueden seguir siendo visibles; además, el nombre del servidor puede exponerse durante el establecimiento en configuraciones que no emplean mecanismos de protección del nombre. Tampoco impide que el propio sitio, una extensión maliciosa o un equipo comprometido accedan a los datos una vez que se descifran en el extremo.

Una conexión HTTPS tampoco garantiza cifrado de extremo a extremo entre dos personas. El servidor termina la conexión TLS y puede leer los datos que recibe para prestar el servicio. Transporte cifrado no equivale a contenido inaccesible para el proveedor: para este último objetivo hace falta un diseño de cifrado de extremo a extremo en el que el servicio no controle las claves de descifrado.

openssl s_client permite abrir una conexión TLS a un servidor y observar información de la negociación, como el protocolo seleccionado, el conjunto de cifrado y los certificados que presenta. Para un dominio de prueba, una comprobación básica es:

openssl s_client -connect example.com:443 -servername example.com -showcerts

La opción -servername envía el nombre mediante SNI, necesario cuando varios sitios comparten una misma dirección IP. Sin SNI, el servidor podría responder con un certificado predeterminado que no corresponde al dominio que se quería revisar. Sustituye example.com por el nombre que administras o tienes permiso para comprobar.

La salida no es un dictamen completo de seguridad. Examina el protocolo y el cifrado negociados, la cadena que presenta el servidor y el código de verificación. La verificación puede depender del almacén de autoridades de confianza de la instalación local de OpenSSL; un resultado correcto en una máquina no prueba cómo se comportarán todos los navegadores o dispositivos.

Para solicitar una conexión concreta con TLS 1.3, si la versión local de OpenSSL lo admite, añade -tls1_3; para TLS 1.2, usa -tls1_2. Esas opciones sirven para comprobar compatibilidad con una versión, pero una conexión fallida puede deberse a la política del servidor, a la red o a la implementación local. No cambies la configuración de producción basándote en una sola prueba.

En el navegador, el panel de información del sitio permite revisar la conexión y los datos del certificado, aunque la ruta exacta depende del navegador y su versión. Para una revisión práctica, comprueba al menos el nombre cubierto, el emisor, la vigencia y si la página se ha cargado mediante HTTPS. Las herramientas de desarrollo pueden mostrar además información de seguridad y de solicitudes, pero no sustituyen una revisión de configuración del servidor.

Los fallos de handshake son síntomas, no diagnósticos: pueden aparecer cuando cliente y servidor no comparten una versión o un conjunto de cifrado, cuando el certificado no es válido para el nombre solicitado, cuando falta un certificado intermedio o cuando hay problemas de SNI. Un reloj incorrecto también puede hacer que un certificado parezca todavía no vigente o ya vencido. Identificar la causa evita “arreglos” que eliminan protecciones.

En un servicio web, el administrador debería mantener protocolos y algoritmos compatibles con los clientes que realmente necesita, y retirar opciones obsoletas de acuerdo con su política de seguridad. TLS 1.3 reduce las opciones criptográficas heredadas; TLS 1.2 todavía puede ser necesario para compatibilidad, pero su seguridad depende de la selección concreta de parámetros. No basta con activar una versión sin revisar el conjunto completo de configuración.

Una lista útil para una primera revisión es:

• Confirmar que el dominio solicitado aparece en el certificado y que este está vigente.
• Revisar si se envía la cadena de certificados necesaria y si el servidor usa el certificado correcto mediante SNI.
• Comprobar qué versión TLS y conjunto de cifrado se negocian con clientes representativos.
• Investigar los registros del servidor y la salida de OpenSSL antes de modificar políticas.
• Evitar desactivar la validación del certificado o reactivar protocolos obsoletos como solución rápida.

No desactives la validación para hacer desaparecer un aviso. Si el problema es una cadena incompleta, un nombre incorrecto o un certificado vencido, ignorar la comprobación convierte un error visible en una conexión menos confiable. La decisión práctica es corregir la causa en el servidor o en el cliente, no aceptar a ciegas una identidad que no ha podido verificarse.