- La comunicación en internet tiene una estructura donde varias capas se reparten el manejo de los paquetes, y gracias a los protocolos en capas, los desarrolladores no necesitan encargarse directamente de los detalles de implementación de transporte, enrutamiento o seguridad
- Una solicitud HTTP sigue un flujo por etapas que comienza con la creación del mensaje en el navegador, continúa con la consulta DNS, el TCP 3-way handshake, el paso por routers y termina con la respuesta del servidor
- HTTP básico envía encabezados y cuerpo en texto plano, por lo que es vulnerable a la interceptación y a la suplantación del servidor; para cubrir esa limitación, se añadió una capa de seguridad
- HTTPS es HTTP con cifrado y verificación TLS añadidos, y el TLS handshake es el proceso de acordar versión,
cipher suite, certificado e información de intercambio de claves para crear una clave de sesión simétrica
- TLS 1.3 elimina RSA y los
cipher suite y parámetros débiles, reduciendo las opciones para lograr un handshake más simple, rápido y seguro que en métodos anteriores
Modelo por capas para entender la comunicación en internet
- Internet es una red de redes de computadoras interconectadas, y “Internet” literalmente significa “entre redes”
- Funciona como una red mallada de conmutación de paquetes, con una estructura de best-effort delivery donde no se garantiza ni la entrega de los paquetes ni el tiempo de llegada
- El internet parece funcionar de forma fluida porque varios niveles de abstracción se encargan por detrás de tareas como reintentos, garantía de orden, eliminación de duplicados y seguridad
- Cada capa ofrece una función específica, y distintos protocolos pueden implementar esa función
- Gracias a esta modularidad, se puede cambiar el protocolo de una capa sin afectar necesariamente a los protocolos de las demás capas
Rol de cada capa de red
- La Application layer maneja la lógica específica de cada aplicación; su unidad de comunicación es el mensaje, y HTTP es un ejemplo representativo
- La Security layer proporciona cifrado y autenticación; su unidad de comunicación es el record, y TLS es un ejemplo
- La Transport layer se encarga de la transmisión confiable de datos; usa segmentos TCP o datagramas UDP y se identifica por números de puerto
- La Network layer enruta paquetes a través de internet y usa direcciones IP como identificador
- La Link layer administra la comunicación cercana al medio físico; usa frames y se identifica por direcciones MAC
- La Physical layer transmite bits físicamente entre dispositivos; ejemplos son la fibra óptica y el cable Ethernet
Flujo de una solicitud HTTP
Cómo llegan los paquetes al servidor
- Cuando el cliente envía la solicitud, los paquetes de datos no van directamente al servidor; encuentran una ruta hasta la gateway de la red del servidor pasando por varios equipos de red y routers
- Después, la Link layer se encarga de la transmisión en el tramo local
-
Etapas de cómo el texto cruza internet
- El dispositivo cliente encapsula los datos de la solicitud HTTP en un segmento TCP, y luego lo envuelve en un paquete IP
- Si es una conexión cableada, se encapsula una vez más en un frame de Link layer, como un frame Ethernet
- El frame se transmite por la red local hacia el router del cliente
- El router local recibe el frame, elimina el header de Link layer y procesa el paquete IP
- El router mira la dirección IP de destino y decide el siguiente hop
- El paquete se reenvía a la siguiente red pasando por uno o más routers intermedios, y cada router repite el proceso de elegir el siguiente hop y reenviar
- Al final, el paquete llega a un router que está en la misma red que el servidor de destino
- Ese router toma la decisión final de enrutamiento y envía el paquete al dispositivo local correspondiente al servidor
- El router del servidor entrega el paquete al servidor a través del segmento de red local
- La Link layer se asegura de que el frame llegue correctamente a la interfaz de red del servidor
- El servidor recibe el frame, extrae el paquete IP y procesa el segmento TCP encapsulado para reconstruir la solicitud HTTP original
- El proceso de la Network layer que envía paquetes a través de internet también se usa en etapas anteriores, como la resolución de nombres de dominio o el TCP handshake
Respuesta del servidor y renderizado del navegador
- Después de procesar la solicitud HTTP, el servidor envía una respuesta HTTP al cliente
- La respuesta incluye la versión de HTTP en uso, un código de estado como
200 o 404, encabezados de respuesta y un cuerpo con datos como el HTML de la página solicitada o JSON
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456
Example Page
Hello, world!
- El cliente recibe y procesa la respuesta HTTP
- El navegador interpreta el HTML y renderiza el contenido en pantalla
- Si la respuesta incluye recursos adicionales como imágenes, CSS o JavaScript, el navegador envía solicitudes HTTP adicionales siguiendo el mismo proceso
Problemas de seguridad de HTTP y HTTPS
- HTTP básico no tiene ninguna seguridad
- Cualquiera que escuche la conexión puede ver el 100% de los datos intercambiados
- Si alguien se hace pasar por el servidor, el cliente puede enviar información sensible al destino equivocado
- HTTPS es HTTP con cifrado y verificación añadidos
- Hay varias formas de hacer segura la comunicación HTTP, pero la implementación de uso general hoy es TLS
- TLS permite que el cliente y el servidor verifiquen mutuamente la identidad y cifren el payload de forma que ambas partes puedan descifrarlo
- El flujo de una solicitud HTTPS es igual al de una solicitud HTTP visto antes, pero se añade una Security layer entre la Application layer y la Transport layer
- Normalmente se usa TCP para el TLS handshake
Qué se acuerda en el TLS handshake
- El TLS handshake es el proceso en el que cliente y servidor acuerdan varios elementos que usarán en la comunicación
- Entre esos elementos están el conjunto de algoritmos para verificación de mensajes, compresión y cifrado
- A este conjunto de algoritmos se le llama cipher suite
- En sentido estricto, el
cipher suite excluye el algoritmo de compresión, pero en este texto se usa el término para todo el conjunto
- Algunos componentes de ejemplo son los siguientes
- Compression algorithm: la forma de comprimir datos sobre el wire; ejemplos son Gzip y Brotli, y actualmente se usa principalmente Brotli
- Key exchange algorithm: la forma de intercambiar de manera segura claves de cifrado por un canal público; ejemplos son ECDHE-RSA y ECDHE-ECDSA, y hoy se usa principalmente ECDHE
- Authentication algorithm: la forma de autenticar la identidad de las partes durante el handshake; ejemplos son RSA y ECDSA, y RSA se usa ampliamente, aunque ECDSA también está ganando popularidad
- Symmetric encryption algorithm: la forma de cifrar los datos entre cliente y servidor; ejemplos son AES-128-GCM y AES-256-GCM, y AES-GCM ofrece fuerte seguridad y eficiencia
- MAC algorithm: la forma de garantizar la integridad y autenticidad de los mensajes; ejemplos son HMAC-SHA256 y HMAC-SHA384, y se usan HMAC-SHA256 y el modo GCM en los
cipher suite modernos
- Cliente y servidor acuerdan un
cipher suite e intercambian un seed aleatorio y la información del SSL certificate para poder crear una clave simétrica que servirá para cifrar y verificar mensajes
- La fuente del material sobre TLS handshake es Cloudflare
Etapas del TLS handshake tradicional
-
Client Hello
- El cliente envía al servidor un mensaje TCP con los
cipher suite que soporta, la versión de TLS compatible y un número aleatorio llamado Client Random
-
Server Hello
- El servidor responde con un mensaje TCP que incluye la versión de TLS elegida, el algoritmo de
cipher suite seleccionado y Server Random
-
Certificate Verification
- El cliente verifica el SSL certificate del servidor a través de una Certificate Authority y obtiene la public key del servidor
-
Premaster Secret Generation
- El cliente crea el premaster secret, lo cifra con la public key del servidor y lo envía al servidor
-
Decryption
- El servidor usa su private key para descifrar el premaster secret
-
Session Key Creation
- Cliente y servidor crean la session key usando Client Random, Server Random y el premaster secret
-
Client Ready
- El cliente envía el mensaje
finished cifrado con la session key
-
Server Ready
- El servidor envía el mensaje
finished cifrado con la session key
-
Secure HTTP Communication
- A partir de ahí, ambas partes se comunican usando cifrado simétrico seguro con la session key
Qué cambió en TLS 1.3
- El TLS handshake explicado antes corresponde al proceso de versiones antiguas de TLS, y según el estándar actual de TLS 1.3 ya se considera un método viejo
- TLS 1.3 y versiones posteriores ya no soportan RSA ni varios
cipher suite por razones de seguridad
- Las versiones modernas reducen mucho las opciones, lo que las hace más simples, más seguras y más rápidas
- El concepto central se mantiene también en TLS 1.3
- Mediante el handshake se acuerdan el método de compresión, la autenticación del servidor y el intercambio de claves
- Se genera una clave de cifrado simétrico para proteger los datos de los paquetes intercambiados por TCP
- TLS 1.3 no admite
cipher suite ni parámetros vulnerables a ataques, y reduce el handshake para hacerlo más rápido y seguro
-
Etapas básicas del handshake en TLS 1.3
- Client hello: el cliente envía la versión del protocolo, Client Random y la lista de
cipher suite
- En TLS 1.3 se eliminó el soporte para
cipher suite inseguros, por lo que la cantidad de opciones posibles se reduce mucho
- El Client hello también incluye los parámetros que se usarán para calcular el premaster secret
- El cliente asume que conoce el key exchange method preferido del servidor, y eso es más probable debido a la lista reducida de
cipher suite
- Esta estructura reduce la longitud total frente a los handshakes de TLS 1.0, 1.1 y 1.2
- Server generates master secret: el servidor recibe Client Random, los parámetros del cliente y el
cipher suite, y como puede generar por su cuenta el Server Random, puede crear el master secret
- Server hello and
Finished: el Server hello incluye el certificate del servidor, la digital signature, Server Random y el cipher suite elegido
- Como el servidor ya tiene el master secret, también envía el mensaje
Finished
- Final steps and client
Finished: el cliente verifica la signature y el certificate, genera el master secret y luego envía el mensaje Finished
- Secure symmetric encryption achieved: después de eso, queda establecido el cifrado simétrico seguro
1 comentarios
Opiniones de Hacker News
Como no especialista, me da curiosidad por qué es tan difícil saber en qué tramo ocurrió la falla cuando no se puede acceder a un sitio web específico o a todo Internet.
A menudo no queda claro si es un error en la configuración de red de mi máquina local, un problema con la conexión Wi-Fi hasta el router, un problema con el cable entre el router y el ISP, una caída masiva del ISP o una falla del sitio web al que intento entrar.
He escuchado una explicación vaga de que se debe a que las solicitudes se enrutan por rutas no deterministas, pero no resulta muy convincente. Me pregunto por qué, si se corta algún enlace en la ruta, el último enlace que funciona no puede avisar hacia atrás: “tu mensaje llegó hasta aquí, pero fallé al intentar enviarlo al siguiente paso”.
Las configuraciones varían mucho, no se puede saber qué configuración era la intencional, y es peligroso hacer suposiciones basadas en causas comunes y terminar dando una respuesta totalmente equivocada.
Por ejemplo, si ni el servidor DNS ni el host de destino responden, podrías decir que es un error de configuración del router o una caída del ISP, pero la causa real podría ser que un cliente VPN cambió la tabla de enrutamiento local y los servidores DNS, y luego no los restauró al cerrarse. El problema es cómo podría saber un diagnosticador si se trata de un cambio temporal o de una configuración permanente.
Las aplicaciones no ven los mensajes ICMP a menos que configuren el socket para ello. Esto se trata como un error “temporal”, y en Linux se configura con la opción de socket
IP_RECVERR.Cuando trabajas en la capa 7, recopilar errores de esta capa no aporta demasiado valor. Los errores Destination Unreachable que afloren hacia arriba se ajustarán a la lógica de manejo de fallas que ya tendrás implementada y, en este caso, como las demás capas reintentan contra destinos inalcanzables, probablemente se verá como un timeout.
Estos RFC ayudan a entender cómo maneja la capa TCP los errores ICMP: https://www.rfc-editor.org/rfc/rfc1122#page-103
En 4.2.3.9 se indica que los mensajes Unreachable son una condición de soft error, por lo que TCP no debe abortar la conexión y debe proporcionar la información a la aplicación. TCP puede elevarla a la capa de aplicación mediante la rutina ERROR_REPORT, o registrar el mensaje y reportarlo a la aplicación solo cuando la conexión TCP expire por timeout.
También hay un documento que cubre con más detalle cómo interactúan las pilas para estudiar ICMP como vector de ataque contra TCP: https://www.rfc-editor.org/rfc/rfc5927
Si no se puede llegar al propio servidor DNS, entonces hay algún error de red entre el usuario y ese servidor. Normalmente se diagnostica ejecutando los pasos manualmente: verificar si se puede hacer ping a la dirección del servidor DNS, si ese servidor DNS puede resolver ese host y qué ocurre con otros servidores DNS. También puede que ciertas políticas corporativas excluyan algunos nombres.
Si quieres profundizar más, son útiles las herramientas de línea de comandos como
ping,tracerouteydig.MTR es como ping + traceroute corriendo continuamente en tiempo real, y muestra cada salto por separado.
Incluso cuando detecté por primera vez que un nodo de la red de Xfinity estaba caído, era consistente porque en el mismo MTR podía ver que al menos desde mi red hasta el módem todo estaba bien. No he visto muchas herramientas que muestren tan bien como MTR que la latencia aumentó cientos de ms en algún salto más allá del ISP.
No resuelve todos los problemas, pero como proporciona la latencia desglosada por salto, vale la pena revisarlo.
Para decir “el problema está aquí” hace falta asumir cosas sobre cómo están configurados el sistema operativo, el hardware y la red.
Al entrar a un sitio web, primero hay que obtener desde DNS la dirección IP del servidor web, pero ya es complejo de dónde obtiene el navegador la IP del DNS. Puede estar configurada en el navegador, el sistema operativo, el router o el módem; y si no está configurada, se recibe del servidor DHCP al que se conectó el router. Ese podría ser el servidor DHCP del ISP o algún otro router dentro de una organización.
Si el DNS parece raro, es fácil saber que la IP está mal, pero es difícil decir de dónde vino esa IP. Con SSL también puede ser que el certificado del servidor esté mal o que el certificado de mi computadora esté mal.
Puede estar relacionado: también hay ejemplos interactivos que recorren byte por byte en detalle TLSv1.2 y TLSv1.3.
Si quieres aprender más sobre TLS, son recursos que me gustan muchísimo y los recomiendo ampliamente.
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
Me pregunto si hay más ejemplos de textos escritos desde esta perspectiva. Me gustan los textos que explican las cosas “como si se las explicaran a un ingeniero más o menos”, sin importar el nivel de experiencia
En general son muy útiles porque permiten aprender piezas que no estaban del todo claras o conseguir más ejemplos para usar al explicárselo a otra persona
Ejemplos:
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/ssl/transport-layer-secu...
https://www.cloudflare.com/learning/performance/what-is-http...
La explicación de que “el cliente genera el premaster secret, lo cifra con la clave pública del servidor y luego se lo envía al servidor” dejó de ser cierta hace ya mucho tiempo
Agrega que el proceso recién explicado corresponde a versiones iniciales de TLS ya obsoletas en comparación con el TLS 1.3 moderno
La frase “las versiones actuales de TLS (>1.3) no admiten RSA ni varios conjuntos de cifrado por motivos de seguridad” es correcta en la parte de intercambio de claves. Eso se debe a que RSA no ofrece secreto hacia adelante (forward secrecy)
RSA todavía se usa para firmas, y probablemente sea el tipo más extendido en certificados x509
Según tengo entendido, Safari hace poco elevó el requisito de clave a 2048 bits para firmas RSA
Este texto se lee como si una IA hubiera resumido un artículo real que explica HTTPS. Los términos aparecen sin contexto
No explica qué es un certificado ni cómo funciona la cadena de confianza, y asume que el lector conoce la criptografía de clave pública. Explica 6 de las 7 capas del modelo OSI, pero ni siquiera menciona ese término, y falta la capa de presentación
Claro que el título ya dice mediocre
Escribir no es mi punto fuerte, así que acepto con gusto la crítica. Que mi texto haya pasado de “es malo” a “¿es IA?” es un progreso
Estuve pensando dónde cortar la explicación, y consideré que la criptografía de clave pública era un buen límite porque se puede explicar mejor en otros lugares. Lo mismo aplica a varias capas de OSI
Admito que debería haber tratado los certificados y quizá toda la cadena de confianza
No logro encontrar código que muestre la verificación de firma de
SHA256(client_hello_random + server_hello_random + curve_info + public_key)Conozco la teoría, pero al intentar implementarlo algo falla. Me gustaría tener un enlace a un programa de juguete que muestre cómo se hace en la práctica
Espero que no esté diciendo algo como que “el certificado SSL del servidor contiene la clave privada”. Aunque el título sea “Mediocre Engineer”
TLS <1.3 tampoco funciona como lo describe el artículo, y aun así intenta mezclar elementos más nuevos de 1.3. La parte de DNS explica un resolver recursivo, pero el cliente no hace eso; probablemente se comunique con un resolver stub
Siguen apareciendo errores como “Internet Layer”, la insinuación de que brotli es un algoritmo ampliamente usado en la compresión TLS o en conjuntos de cifrado, y “las versiones actuales de TLS (>1.3) no admiten RSA”
Por esta clase de blogspam, a veces quisiera que existiera el downvote. La publicidad no molesta tanto como para marcarla con flag, pero el nivel es bajo. Quizá debería escribir un artículo menos mediocre para llevarlo a la portada de HN. Si ganara US$300K al año, habría tenido más tiempo
El contenido del artículo en general está un poco desactualizado. Hoy en día el 30% de las solicitudes web usa HTTP/3 y también existe CORS, pero no tiene fecha de publicación
Yo normalmente desarrollo sistemas SaaS que se despliegan dentro de redes corporativas, y las solicitudes CORS son casi 0%. Lo mismo con HTTP/3