A seguridade xa non é unha opción, senón un curso obrigatorio para calquera profesional da tecnoloxía de Internet. HTTP, HTTPS, SSL, TLS: entendes realmente o que está a suceder entre bastidores? Neste artigo, explicaremos a lóxica básica dos protocolos de comunicación cifrados modernos dun xeito sinxelo e profesional, e axudarémosche a comprender os segredos "tras os peches" cun diagrama de fluxo visual.
Por que é HTTP "inseguro"? --- Introdución
Lembras ese aviso familiar do navegador?
"A túa conexión non é privada."
Unha vez que un sitio web non implementa HTTPS, toda a información do usuario envíase pola rede en texto sen formato. Os teus contrasinais de inicio de sesión, números de tarxetas bancarias e mesmo conversas privadas poden ser capturados por un pirata informático ben posicionado. A causa principal disto é a falta de cifrado de HTTP.
Entón, como permite que o HTTPS e o "gardián" que o sustenta, o TLS, viaxen os datos de forma segura a través de Internet? Analicemos isto capa por capa.
HTTPS = HTTP + TLS/SSL --- Estrutura e conceptos básicos
1. Que é en esencia HTTPS?
HTTPS (Protocolo de transferencia de hipertexto seguro) = HTTP + capa de cifrado (TLS/SSL)
○ HTTP: É o responsable de transportar os datos, pero o contido é visible en texto plano
○ TLS/SSL: Proporciona un "bloqueo de cifrado" para a comunicación HTTP, convertendo os datos nun crebacabezas que só o remitente e o receptor lexítimos poden resolver.
Figura 1: Fluxo de datos HTTP fronte a HTTPS.
"Lock" na barra de enderezos do navegador é o indicador de seguranza TLS/SSL.
2. Cal é a relación entre TLS e SSL?
○ SSL (Secure Sockets Layer): o protocolo criptográfico máis antigo, que presenta vulnerabilidades graves.
○ TLS (Seguridade da capa de transporte): o sucesor de SSL, TLS 1.2 e o máis avanzado TLS 1.3, que ofrecen melloras significativas en seguridade e rendemento.
Hoxe en día, os "certificados SSL" son simplemente implementacións do protocolo TLS, simplemente chamadas extensións.
Afondando no TLS: A maxia criptográfica detrás de HTTPS
1. O fluxo de handshake está totalmente resolto
A base da comunicación segura TLS é a danza do handshake no momento da configuración. Analicemos o fluxo estándar do handshake TLS:
Figura 2: Un fluxo típico de handshake TLS.
1️⃣ Configuración da conexión TCP
Un cliente (por exemplo, un navegador) inicia unha conexión TCP co servidor (porto estándar 443).
2️⃣ Fase de aperto de mans TLS
○ Client Hello: O navegador envía a versión de TLS compatible, o cifrado e o número aleatorio xunto coa Indicación do nome do servidor (SNI), que lle indica ao servidor a que nome de host quere acceder (o que permite compartir IP entre varios sitios).
○ Problema de certificado e saúdo do servidor: o servidor selecciona a versión e o cifrado TLS axeitados e devolve o seu certificado (coa clave pública) e números aleatorios.
○ Validación de certificados: o navegador verifica a cadea de certificados do servidor ata a CA raíz de confianza para garantir que non foi falsificada.
○ Xeración de claves premaster: o navegador xera unha clave premaster, a cifra coa clave pública do servidor e a envía ao servidor. Dúas partes negocian a clave de sesión: usando os números aleatorios de ambas partes e a clave premaster, o cliente e o servidor calculan a mesma clave de sesión de cifrado simétrico.
○ Finalización do handshake: Ambas as partes envían mensaxes "Finalizado" entre si e entran na fase de transmisión de datos cifrados.
3️⃣ Transferencia segura de datos
Todos os datos do servizo están cifrados simetricamente coa clave de sesión negociada de forma eficiente; mesmo se se interceptan no medio, son só un feixe de "código ilusorio".
4️⃣ Reutilización da sesión
TLS volve ser compatible con Session, o que pode mellorar moito o rendemento ao permitir que o mesmo cliente omita o tedioso handshake.
O cifrado asimétrico (como RSA) é seguro pero lento. O cifrado simétrico é rápido pero a distribución de claves é complicada. TLS usa unha estratexia de "dous pasos": primeiro un intercambio de claves seguras asimétricas e despois un esquema simétrico para cifrar os datos de forma eficiente.
2. Evolución dos algoritmos e mellora da seguridade
RSA e Diffie-Hellman
○ RSA
Foi amplamente utilizado por primeira vez durante o protocolo de enlace TLS para distribuír de forma segura as claves de sesión. O cliente xera unha clave de sesión, cífraa coa clave pública do servidor e envíaa para que só o servidor a poida descifrar.
○ Diffie-Hellman (DH/ECDH)
A partir de TLS 1.3, RSA xa non se usa para o intercambio de claves en favor dos algoritmos DH/ECDH máis seguros que admiten o segredo de reenvío (PFS). Mesmo se se filtra a clave privada, os datos históricos aínda non se poden desbloquear.
| Versión TLS | algoritmo de intercambio de claves | Seguridade |
| TLS 1.2 | RSA/DH/ECDH | Máis alto |
| TLS 1.3 | só para DH/ECDH | Máis alto |
Consellos prácticos que os profesionais de redes deben dominar
○ Actualización prioritaria a TLS 1.3 para un cifrado máis rápido e seguro.
○ Activar cifrados fortes (AES-GCM, ChaCha20, etc.) e desactivar algoritmos débiles e protocolos inseguros (SSLv3, TLS 1.0);
○ Configurar HSTS, grapado OCSP, etc. para mellorar a protección xeral de HTTPS;
○ Actualizar e revisar regularmente a cadea de certificados para garantir a validez e a integridade da cadea de confianza.
Conclusión e reflexións: É o teu negocio realmente seguro?
Desde o HTTP de texto plano ata o HTTPS totalmente cifrado, os requisitos de seguridade evolucionaron tras cada actualización do protocolo. Como pedra angular da comunicación cifrada nas redes modernas, TLS mellórase constantemente para facer fronte ao entorno de ataque cada vez máis complexo.
A súa empresa xa usa HTTPS? A súa configuración criptográfica aliñase coas mellores prácticas do sector?
Data de publicación: 22 de xullo de 2025
