Que anade HTTPS sobre HTTP
El handshake de TLS, los certificados y la cadena de confianza detras de ellos, que puede y que no puede hacer un hombre en el medio, y por que el secreto hacia adelante cambia cuanto vale una clave robada.
HTTP es texto en claro. Todo lo que escribes en un formulario, cada cookie de sesion y cada token de API viaja como bytes legibles, y cualquier dispositivo en la ruta puede no solo leerlos sino cambiarlos sin que ninguna de las dos partes lo note. HTTPS es el mismo HTTP dentro de TLS. Lo interesante no es el cifrado, sino que ambos extremos logren acordar una clave secreta mientras un atacante escucha cada mensaje de la negociacion.
El handshake es esa negociacion, y ocurre antes de cualquier peticion. El cliente abre una conexion TCP y envia un ClientHello con un numero aleatorio, la lista de cifrados que admite y su parte publica de clave. El servidor responde con su propio aleatorio, el cifrado elegido y su parte de clave. Despues ambos lados derivan las mismas claves de sesion a partir de su valor privado y del valor publico ajeno, y nadie que escuche la conversacion puede repetir ese calculo. Al final los dos envian un mensaje Finished que es un hash de todo lo dicho hasta entonces, de modo que cualquier modificacion durante el handshake rompe la comprobacion de inmediato.
Un certificado es una declaracion firmada que vincula una clave publica con un nombre de host. Contiene el nombre, la clave publica, una ventana de validez y una firma hecha por una autoridad de certificacion. Esa firma es lo que hace confiable la clave: la clave por si sola no prueba nada. Si aceptas cualquier clave que te ofrezcan, un atacante simplemente ofrece la suya.
Chain
1 leaf CN=example.org
SAN: example.org, www.example.org
valid 2026-01-01 .. 2026-04-01
2 intern CN=R3 Intermediate CA
3 root CN=ISRG Root X1 (already on the device)
Validation
signature of 1 checked with public key of 2 ok
signature of 2 checked with public key of 3 ok
signature of 3 checked with public key on device ok
name in SAN matches the host that was requested ok
current time inside the validity window okUna cadena de certificados y las cinco comprobaciones que hace un cliente.La cadena es lo que permite que unas pocas raices basten para toda la web. Una autoridad raiz firma una intermedia, la intermedia firma el certificado que recibes, y tu dispositivo solo tiene que confiar de antemano en la raiz: los certificados raiz vienen con el sistema operativo y el navegador. La validacion recorre la cadena hacia arriba: comprueba la firma del certificado final con la clave de la intermedia, la intermedia con la raiz, que la raiz sea de confianza, y despues que el nombre del certificado coincida con el host que pediste y que la fecha de hoy caiga dentro de la ventana de validez. Cualquier fallo detiene la conexion.
Un atacante en la ruta que no puede presentar un certificado valido tiene un problema real. Puede descartar o retrasar tus paquetes, puede suplantar una direccion, pero no puede leer los bytes cifrados ni falsificar el handshake sin un certificado que tu cliente acepte. Cambiar un byte cifrado no cambia un bit del texto claro: falla la autenticacion y la conexion termina. Por eso pasar por encima de un aviso de certificado es mala idea: o el aviso es un error de configuracion real, o acabas de entregar tu sesion a quien lo provoco.
$ curl -v https://example.org
* SSL certificate problem: self-signed certificate in certificate chain
* Closing connection
$ curl -vk https://example.org
* Server certificate: CN=mitm-proxy.local
* subjectAltName does not match example.org
< HTTP/1.1 200 OKLa misma peticion con y sin comprobacion del certificado.El secreto hacia adelante responde a una pregunta concreta: que pasa con el trafico grabado hace anos si hoy se filtra la clave privada del servidor? En el intercambio clasico la clave de sesion se cifraba con la clave publica del servidor, asi que un handshake grabado mas la clave filtrada bastan para descifrarlo todo. Con Diffie-Hellman efimero la parte de clave se genera para esa unica conexion y se descarta despues, de modo que una filtracion posterior no sirve contra el trafico pasado. No debilita a un atacante activo ni ayuda si ya tiene la clave de sesion. Cambia el valor de una clave robada: de toda la historia a una sola sesion.
Práctica
Ordena los eventos de una primera solicitud HTTPS a un host con el que nunca has contactado.
- 1se intercambian la solicitud y la respuesta HTTP cifradas
- 2el servidor presenta su cadena de certificados
- 3el cliente envia un ClientHello con datos aleatorios y una parte de la clave
- 4el cliente abre una conexion TCP al puerto 443
- 5ambas partes terminan el handshake y derivan las mismas claves de sesion
- 6el servidor responde con sus propios datos aleatorios, su cifrado elegido y su parte de la clave
Pistas
- No se puede enviar nada cifrado antes de que ambas partes hayan acordado cómo cifrarlo.
- El certificado llega desde el servidor después de que se hayan intercambiado los dos mensajes hello.
- Los datos de aplicación son lo último de todo: antes el handshake debe haber terminado en ambos lados.
Un servidor presenta un certificado emitido por una autoridad de confianza para el nombre de host correcto, pero caduco hace tres dias. El navegador se niega a conectar. Que significa realmente esa negativa?
Pistas
- Pregunta qué demuestra el certificado: es una firma de una autoridad, no una promesa sobre el software del servidor.
- Un certificado con una firma perfectamente válida puede seguir siendo de un nombre de host distinto del que escribiste.
- Un certificado caducado o revocado es un rechazo normal y esperado, y el navegador lo informa de forma muy visible.
Relaciona cada atacante o fallo con lo que realmente puede conseguir contra una conexion HTTPS moderna.
Pistas
- Separa a los atacantes por lo que pueden hacer: leer y cambiar bytes, o simplemente copiarlos y esperar.
- El secreto hacia adelante trata del tráfico grabado hace mucho tiempo y descifrado mucho después, cuando una clave ya se ha filtrado.
- Un observador pasivo en la ruta igual se entera de los nombres de los sitios que visitas, aunque el contenido de las páginas permanezca oculto.
Preguntas sobre esta lección
¿Para qué aprender redes?
Casi todo lo que construyes acaba hablando con otra cosa. Entender cómo viajan de verdad los datos convierte «no funciona» en una lista de cosas que puedes comprobar una a una.
¿Cuál es la diferencia real entre TCP y UDP?
TCP se asegura de que todo llegue y en orden, y reintenta lo perdido, a cambio de tiempo. UDP envía y no mira atrás; por eso el vídeo en vivo y los juegos lo prefieren: un fotograma tardío es peor que uno perdido.
¿Qué es DNS en palabras simples?
Es la guía telefónica de internet. Tú conoces el nombre, el ordenador necesita el número. DNS convierte un nombre como example.org en una dirección IP y guarda la respuesta para no preguntar cada vez.
¿Es gratis?
Sí. El primer nivel de cada materia es gratis y no necesita cuenta. Los niveles más profundos y los grados superiores son de pago: eso es lo que mantiene vivo el proyecto.
¿Para qué edad es?
Está escrito para adolescentes curiosos a partir de unos 12 años y para adultos que empiezan de cero. No se supone experiencia previa en programación; las lecciones de redes y física no necesitan matemáticas más allá del colegio.
¿Necesito saber programar ya?
No. Las rutas de lógica, física y redes empiezan desde cero. El código lo escribes en la sección de lenguajes, que también arranca desde el principio.
¿Hay que instalar algo?
No. Todo funciona en el navegador: teoría, práctica y las simulaciones interactivas. No hay nada que descargar ni que configurar.
¿Cuánto se tarda en una materia?
Una lección dura entre 10 y 15 minutos. Un grado junior son unas 12 a 20 lecciones, así que son unas semanas de práctica constante, no una tarde.
¿Hay que seguir el orden?
Dentro de un grado los niveles se abren uno tras otro, porque cada uno se apoya en el anterior. Entre materias eres libre: empieza por lógica, física o redes.