Tema 8: Internet: arquitectura, servicios y protocolos

Arquitectura y evolución de Internet

Internet es una red de redes de alcance mundial que interconecta equipos heterogéneos mediante la familia de protocolos TCP/IP. Su arquitectura es descentralizada y basada en la conmutación de paquetes: los datos se fragmentan, viajan de forma independiente por distintos caminos y se reensamblan en destino. Nació a finales de los años 60 con ARPANET (financiada por la agencia DARPA del Departamento de Defensa de EE. UU.), evolucionó con la adopción de TCP/IP como protocolo estándar en 1983, se abrió al ámbito académico con NSFNET y explotó a nivel global tras la creación de la World Wide Web por Tim Berners-Lee en el CERN (1989-1991). El estado actual se caracteriza por la coexistencia de IPv4 e IPv6, la banda ancha y móvil, la nube y el Internet de las Cosas.

Clasificación de redes por su alcance geográfico

Según la extensión física que cubren, las redes se clasifican en:

Así, para conectar dispositivos dentro de una oficina, un edificio o un campus se emplea una LAN, mientras que para interconectar equipos a escala de una ciudad se utiliza una MAN.

Organismos de gobernanza y estandarización

Internet no tiene un propietario único, sino un conjunto de organismos que coordinan su funcionamiento:

• IETF (Internet Engineering Task Force): es el organismo creador de estándares en Internet. Desarrolla y publica las especificaciones técnicas en forma de documentos RFC (Request for Comments), que definen protocolos como TCP, IP, HTTP o DNS. Trabaja de forma abierta y basada en el consenso.

• IANA (Internet Assigned Numbers Authority): gestiona a alto nivel el espacio global de direcciones IP, los números de sistema autónomo y la raíz del DNS. Delega la distribución regional en los RIR.

• RIR (Regional Internet Registries): son los cinco registros regionales responsables de la asignación y administración de los recursos de numeración de Internet (direcciones IPv4/IPv6, números de sistema autónomo y resolución inversa) en su zona:

Por tanto, el RIR responsable de las direcciones IP de América Latina y el Caribe es LACNIC, cuya función principal es precisamente la asignación y administración de los recursos de numeración de Internet para esa región. Los cinco RIR se coordinan a través de la NRO (Number Resource Organization).

Direccionamiento IPv4

Una dirección IPv4 se compone de 32 bits organizados en cuatro octetos separados por puntos (notación decimal con puntos), donde cada octeto toma un valor de 0 a 255 (por ejemplo, 192.168.1.1). Existen distintas formas legales de escribir una dirección IPv4 —notación decimal con puntos, pero también notaciones hexadecimal, octal o entera de 32 bits admitidas por muchas implementaciones—, por lo que ante dos formatos correctos la respuesta válida es que ambas son legales. Las direcciones se dividen tradicionalmente en clases (A, B, C, D, E) y hoy se gestionan mediante CIDR (enrutamiento sin clases).

NAT e IP Masquerade

La técnica que permite dar acceso a Internet a todos los equipos de una red interna a través de una única IP externa (pública) es el enmascaramiento de direcciones. En el mundo Linux/iptables recibe el nombre de IP Masquerade (masquerading), una forma de NAT (Network Address Translation) de origen dinámico: el router traduce las direcciones IP privadas de la LAN a su única IP pública, multiplexando las conexiones mediante puertos (PAT). Esto alivia el agotamiento de IPv4 y aporta cierto aislamiento.

Cortafuegos (firewalls)

Un cortafuegos filtra el tráfico de red según reglas de seguridad. Según su profundidad de análisis se distinguen: filtrado de paquetes sin estado, cortafuegos con inspección de estado (stateful) y los de inspección profunda. Un cortafuegos DPI (Deep Packet Inspection) es el más avanzado, ya que permite una inspección profunda del contenido completo del paquete —no solo de las cabeceras de red y transporte, sino también de los datos de la capa de aplicación (payload)—, lo que posibilita detectar malware, aplicaciones concretas o intrusiones.

Alta disponibilidad: clústeres y balanceo de carga

Un clúster es un conjunto de servidores que actúan de forma coordinada. La arquitectura de clúster que permite que un conjunto de servidores comparta la carga de trabajo y el tráfico es el balanceo de carga (load balancing): un distribuidor (balanceador) reparte las peticiones entrantes entre varios nodos según algoritmos como round-robin, menor número de conexiones o ponderación. Aporta escalabilidad y alta disponibilidad, frente a los clústeres de failover (activo-pasivo) orientados solo a tolerancia a fallos.

Comandos para obtener la dirección física (MAC)

La dirección MAC es el identificador físico de 48 bits de una interfaz de red. Para consultarla:

• En Linux: el comando ifconfig -a muestra todas las interfaces con su dirección física (campo HWaddr/ether). También son válidos ip link show o ip a.

• En Windows: el comando getmac devuelve la dirección MAC de los adaptadores; también sirve ipconfig /all.

TCP Keep-Alive (RFC 1122)

El mecanismo Keep-Alive de TCP, descrito en el RFC 1122, sirve para comprobar si la conexión con otro dispositivo sigue activa. Sobre una conexión inactiva, el emisor envía periódicamente un segmento de sondeo (keep-alive probe) con número de secuencia SND.NXT-1; si el otro extremo sigue vivo responde con un ACK, y si la conexión se ha perdido (caída o partición de red) responde con un RST. El RFC 1122 exige que una implementación no interprete la falta de respuesta a un único sondeo como conexión muerta y que el keep-alive sea configurable y, por defecto, desactivado. Este sondeo detecta conexiones semiabiertas y libera recursos.

Fuentes

• IETF – RFC 1122, Requirements for Internet Hosts – Communication Layers (§4.2.3.6 TCP Keep-Alives): https://datatracker.ietf.org/doc/html/rfc1122

• IETF, sobre la organización y los estándares (RFC): https://www.ietf.org/

• LACNIC – Registro de Direcciones de Internet para América Latina y el Caribe: https://www.lacnic.net/

• LACNIC en Wikipedia (función RIR): https://en.wikipedia.org/wiki/LACNIC

• IANA – Number Resources / RIRs: https://www.iana.org/numbers

• NRO – Number Resource Organization (los 5 RIR): https://www.nro.net/about/rirs/

• The TCP/IP Guide / RFC 791 – Formato de direcciones IPv4: https://datatracker.ietf.org/doc/html/rfc791

• Linux IP Masquerade HOWTO (The Linux Documentation Project): https://tldp.org/HOWTO/IP-Masquerade-HOWTO/

• Microsoft Learn – comando getmac: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/getmac

Servicios de Internet

Internet se estructura sobre la arquitectura TCP/IP, cuyo modelo de cuatro capas (Acceso a red, Internet, Transporte y Aplicación) sostiene un conjunto de servicios que los usuarios consumen a diario. La inmensa mayoría de esos servicios (web, correo, transferencia de ficheros, resolución de nombres, sincronización horaria, gestión de red, etc.) residen en la capa de Aplicación: protocolos como Telnet, HTTP y FTP funcionan en la capa de Aplicación del modelo TCP/IP, apoyándose en la capa de Transporte (TCP/UDP) para el envío fiable o no fiable de datos.

Puertos: clasificación IANA

La IANA (Internet Assigned Numbers Authority) mantiene el registro oficial de puertos. Se dividen en tres rangos:

• Puertos bien conocidos (well-known): 0-1023. Son los puertos inferiores a 1024, reservados para servicios estándar y, en sistemas tipo Unix, privilegiados: solo procesos del sistema operativo (root) pueden abrirlos.

• Puertos registrados: 1024-49151. Asignados por IANA a aplicaciones concretas.

• Puertos dinámicos/privados (efímeros): 49152-65535.

Puertos de los principales servicios

DNS utiliza el puerto 53 tanto en TCP como en UDP (UDP para consultas ordinarias, TCP para transferencias de zona y respuestas grandes). NTP tiene asignado el puerto 123, que es un puerto bien conocido, NO un puerto registrado del sistema operativo (afirmación incorrecta habitual). NNTP usa el 119, IMAP el 143 y QMTP el 209 según el registro de IANA. Es incorrecto asociar a SMTP el puerto 161 (161 es de SNMP); el envío de correo cifrado por SSL emplea el 465/TCP.

DNS y sus registros de recursos

El Sistema de Nombres de Dominio (DNS) traduce nombres a direcciones. Sus tipos de registro más relevantes:

• A — asocia un nombre de dominio a una dirección IPv4.

• AAAA — asocia un nombre de dominio a una dirección IPv6.

• MX (Mail eXchanger) — especifica y apunta a los servidores de correo electrónico de un dominio.

• NS (Name Server) — indica los servidores de nombres autoritativos del dominio.

• SOA (Start Of Authority) — aporta la información sobre las características básicas del dominio y de la zona (servidor primario, correo del responsable, número de serie, tiempos de refresco/expiración).

• TXT — texto libre; se emplea para confirmar la propiedad de un dominio y prevenir el mal uso del correo (SPF, DKIM, DMARC, verificaciones).

En Windows, el comando ipconfig /flushdns purga la caché de resolución DNS. La herramienta NSLOOKUP dispone de dos modos de funcionamiento: interactivo y no interactivo.

Correo electrónico y formatos

El envío de correo se realiza con SMTP (Simple Mail Transfer Protocol) y la recuperación con IMAP o POP3. SMTP responde con códigos numéricos: el 250 indica que la acción solicitada se ha completado (transmisión del mensaje finalizada con éxito), mientras que el 501 señala un error de sintaxis en los parámetros o argumentos de un comando. MIME (Multipurpose Internet Mail Extensions) es una forma estandarizada de indicar la naturaleza y el formato de un documento, archivo o conjunto de datos, permitiendo enviar adjuntos, texto enriquecido y contenidos no ASCII.

Exchange ActiveSync es un protocolo de sincronización basado en HTTP y XML que permite a los dispositivos móviles acceder a información (correo, calendario, contactos) alojada en servidores Microsoft Exchange, incluso trabajando sin conexión.

Transferencia de ficheros y compartición

FTP (File Transfer Protocol) es un protocolo para transferir archivos entre computadoras. Admite distintos tipos de transferencia: el tipo ASCII es adecuado para archivos de texto plano (convierte los finales de línea), mientras que el tipo binario/imagen se usa para archivos que no deben alterarse. Las redes P2P (peer-to-peer) son una tecnología para compartir archivos entre las computadoras de millones de usuarios, sin depender de un servidor central.

Autenticación: Kerberos

Kerberos es un protocolo de autenticación de redes de ordenadores que permite a dos equipos en una red insegura demostrar su identidad de manera segura. Se basa en criptografía de clave simétrica y en un tercero de confianza (KDC) que emite tickets, evitando transmitir contraseñas por la red.

Gestión y monitorización de red

SNMP (Simple Network Management Protocol) es un protocolo de gestión de redes cuya función es comunicar información de gestión de la red entre las estaciones de gestión y los agentes. Se utiliza para la gestión centralizada de dispositivos de red como enrutadores y switches. Nagios es un software que permite la monitorización de las infraestructuras de Tecnologías de la Información de una organización y se apoya en SNMP para recabar el estado de los dispositivos. (Nota: es SNMP, y no SMTP —protocolo de correo—, el que permite monitorizar la actividad de red de Nagios.)

Web y accesibilidad

En el frente web, HTML5 aporta etiquetas semánticas: la etiqueta <nav> define una sección de enlaces de navegación. Las wikis son una herramienta para editar páginas web desde el propio navegador, base de la colaboración documental.

La accesibilidad web (WCAG del W3C) se organiza en cuatro principios (POUR): Perceptible, Operable, Comprensible y Robusto. El principio de la operabilidad exige que los componentes de la interfaz de usuario y la navegación se puedan utilizar por cualquier persona usuaria (manejo por teclado, tiempo suficiente, ausencia de contenido que provoque convulsiones).

Fuentes

• IANA — Service Name and Transport Protocol Port Number Registry: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

• RFC 5321 — Simple Mail Transfer Protocol (códigos 250 y 501): https://datatracker.ietf.org/doc/html/rfc5321

• RFC 1035 — Domain Names, Implementation and Specification (registros DNS): https://datatracker.ietf.org/doc/html/rfc1035

• RFC 3596 — DNS Extensions to Support IPv6 (registro AAAA): https://datatracker.ietf.org/doc/html/rfc3596

• RFC 4120 — The Kerberos Network Authentication Service (V5): https://datatracker.ietf.org/doc/html/rfc4120

• RFC 1157 — A Simple Network Management Protocol (SNMP): https://datatracker.ietf.org/doc/html/rfc1157

• RFC 2046 — MIME Part Two: Media Types: https://datatracker.ietf.org/doc/html/rfc2046

• W3C — HTML Living Standard, elemento nav: https://html.spec.whatwg.org/multipage/sections.html#the-nav-element

• W3C — Web Content Accessibility Guidelines (WCAG) 2.1: https://www.w3.org/TR/WCAG21/

• Microsoft Learn — Exchange ActiveSync: https://learn.microsoft.com/en-us/exchange/clients/exchange-activesync/exchange-activesync

Protocolos HTTP y HTTPS

HTTP (HyperText Transfer Protocol) es el protocolo de nivel de aplicación sobre el que se sustenta la World Wide Web. Sigue un modelo cliente-servidor de tipo petición-respuesta (request-response): el cliente (típicamente un navegador) envía una solicitud y el servidor devuelve una respuesta con un código de estado y, normalmente, un cuerpo (el recurso solicitado). Es un protocolo sin estado (stateless), lo que se complementa con mecanismos como las cookies para mantener sesión. Por defecto, según la IANA, HTTP escucha en el puerto 80 y HTTPS en el puerto 443.

Evolución de las versiones

HTTP/2 aporta mejoras notables de rendimiento: al ser binario y usar compresión de cabeceras necesita menos recursos, y su multiplexación permite a un cliente realizar múltiples peticiones a la vez sobre una única conexión TCP (elimina el bloqueo head-of-line de HTTP/1.1). Su característica Server Push permite al servidor almacenar datos en la caché del cliente previamente a que estos sean pedidos, anticipando recursos que el navegador necesitará.

Métodos HTTP: seguros e idempotentes

Los métodos se clasifican por dos propiedades independientes:

• Seguros (safe): no modifican el estado del servidor (solo lectura). Ejemplos: GET, HEAD, OPTIONS.

• Idempotentes: repetir la misma petición produce el mismo efecto que ejecutarla una vez. Son idempotentes GET, HEAD, PUT, DELETE.

PUT es idempotente pero NO seguro: modifica el recurso (crea o reemplaza), por lo que no es de solo lectura, pero enviarlo N veces deja el recurso en el mismo estado final. POST, en cambio, no es ni seguro ni idempotente.

Códigos de estado

Los códigos se agrupan en cinco clases según su primer dígito:

• 1xx — Informativos.

• 2xx — Éxito.

• 3xx — Redirecciones.

• 4xx — Errores del cliente (la petición contiene sintaxis errónea o no puede satisfacerse por causa del cliente).

• 5xx — Errores del servidor.

Códigos concretos exigidos frecuentemente en examen:

HTTP frente a HTTPS

HTTPS (HTTP Secure) es HTTP transportado sobre una capa de cifrado TLS/SSL. La principal diferencia es que HTTPS es más seguro que HTTP: aporta confidencialidad (cifra el tráfico e impide que otros usuarios puedan interceptar información confidencial), integridad (detecta manipulaciones) y autenticación del servidor mediante certificado digital. Frente a HTTP, que transmite en texto plano, HTTPS ofrece mayor seguridad en la transmisión de datos. Mientras HTTP usa el puerto 80, HTTPS emplea el 443.

HSTS (HTTP Strict Transport Security)

HSTS es una política o mecanismo de seguridad estandarizado (RFC 6797) que sirve para indicar a los navegadores que una web (y todos sus enlaces) debe ser accedida exclusivamente utilizando HTTPS. Mediante la cabecera de respuesta Strict-Transport-Security, permite que el servidor solo pueda responder a peticiones HTTPS, forzando la conexión segura y previniendo ataques de degradación (SSL stripping) y de intermediario (man-in-the-middle).

Seguridad de cookies: el atributo SameSite

Entre los atributos de seguridad de las cookies, SameSite controla si el navegador envía la cookie en peticiones de origen cruzado. Con su valor restrictivo, el navegador solo envía la cookie al servidor si esta se originó en el mismo sitio web al que se intenta contactar, mitigando ataques CSRF. Otros atributos relevantes son Secure (solo se envía por HTTPS) y HttpOnly (inaccesible desde JavaScript).

Fuentes

• IETF — RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2), 2015: https://datatracker.ietf.org/doc/html/rfc7540

• IETF — RFC 2068 / RFC 2616, HTTP/1.1 (1997): https://datatracker.ietf.org/doc/html/rfc2616

• IETF — RFC 7231, HTTP/1.1: Semantics and Content (métodos seguros e idempotentes, códigos de estado): https://datatracker.ietf.org/doc/html/rfc7231

• IETF — RFC 6797, HTTP Strict Transport Security (HSTS): https://datatracker.ietf.org/doc/html/rfc6797

• IANA — Service Name and Transport Protocol Port Number Registry (puertos 80 y 443): https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

• MDN Web Docs — HTTP response status codes: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

• MDN Web Docs — Set-Cookie / SameSite: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie

SSL/TLS y certificados

SSL (Secure Sockets Layer) y TLS (Transport Layer Security) son los protocolos criptográficos que proporcionan comunicaciones seguras a través de una red (Internet). Su objetivo principal es cifrar la información enviada a través de Internet, ofreciendo autenticación y privacidad de la información entre extremos mediante el uso de criptografía. SSL fue desarrollado originalmente por Netscape; TLS es, en esencia, una versión actualizada y más segura de SSL (TLS 1.0 nació como "SSL 3.1"). Por eso la principal diferencia entre ambos es que TLS es más seguro que SSL. Hoy todas las versiones de SSL (2.0 y 3.0) están obsoletas y se emplea TLS, aunque coloquialmente se sigue hablando de "certificado SSL".

Servicios de seguridad que ofrece SSL/TLS

SSL/TLS proporciona:

• Confidencialidad (privacidad): el tráfico viaja cifrado.

• Integridad: detecta manipulaciones del mensaje.

• Autenticación: verifica la identidad de la contraparte mediante certificados X.509 y criptografía asimétrica.

En la práctica clásica de SSL/TLS solo se autentica el servidor (la autenticación del cliente es opcional). Una característica que SSL NO proporciona por sí mismo es el no repudio: garantiza que hablas con el servidor esperado y que nadie lee el canal, pero no genera una prueba jurídica de autoría del mensaje frente a terceros.

Fases básicas del protocolo

El funcionamiento de SSL/TLS se articula en tres fases básicas:

1. Negociar entre las partes el algoritmo que se usará en la comunicación (cipher suite).

2. Intercambio de claves públicas y autenticación basada en certificados digitales.

3. Cifrado del tráfico basado en cifrado simétrico (mucho más rápido que el asimétrico).

Entre las opciones de criptografía de clave pública que ha proporcionado SSL están RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza. Una función esencial del protocolo es coordinar los estados del cliente y del servidor para que ambos apliquen los mismos parámetros de seguridad.

Arquitectura en dos capas (TLS 1.2)

El protocolo TLS versión 1.2 utiliza dos capas: el TLS Record Protocol y el TLS Handshake Protocol.

• TLS Handshake Protocol: es el protocolo que lleva el proceso de autenticación y de negociación de claves para que la transmisión de datos se realice mediante una conexión privada y fiable.

• TLS Record Protocol: encapsula y protege (cifra y verifica la integridad) los datos de aplicación una vez negociada la sesión.

TLS 1.2 (RFC 5246) introdujo mejoras notables: la capacidad de que clientes y servidores especifiquen qué algoritmos de hash y de firma van a aceptar durante el handshake (extensión signature_algorithms), y el uso de SHA-256 en lugar de la combinación MD5-SHA-1 que empleaba SSL 3.0. Esa es una diferencia clave entre TLS 1.2 y SSL 3.0.

Historia y versiones

• SSL 2.0/3.0: desarrolladas por Netscape (SSL 3.0 en 1996).

• TLS fue definido por primera vez en 1999 (RFC 2246, TLS 1.0).

• TLS 1.2: RFC 5246 (2008).

• TLS 1.3: definido en el RFC 8446 (2018).

Novedades de TLS 1.3 (RFC 8446)

TLS 1.3 supone un rediseño frente a TLS 1.2:

• Handshake en 1-RTT: permite completar el handshake en un solo viaje de ida y vuelta (1-RTT), reduciendo la latencia (TLS 1.2 requería 2-RTT).

• Modo 0-RTT: un modo que permite a los clientes enviar datos antes de que se complete el handshake (reanudación de sesión), a costa de perder protección frente a repetición para esos datos iniciales.

• Eliminación de mecanismos inseguros: TLS 1.3 elimina el soporte para el intercambio de claves RSA estática y Diffie-Hellman estático, forzando esquemas con confidencialidad hacia el futuro (forward secrecy).

• Nuevo mensaje EncryptedExtensions: en TLS 1.3 se añade el mensaje EncryptedExtensions, que es un tipo de mensaje del handshake, NO una extensión del protocolo (esta distinción es habitual en las preguntas: EncryptedExtensions no figura entre las extensiones de TLS 1.3, sino entre sus mensajes).

• Mensajes de negociación: los parámetros de seguridad se negocian con mensajes como ClientHello, ServerHello, EncryptedExtensions, Certificate, CertificateVerify y Finished. El mensaje HelloRequest fue eliminado en TLS 1.3, por lo que HelloRequest NO es uno de los tipos de mensaje con los que TLS 1.3 negocia la conexión.

Algoritmos de cifrado asociados

• DES (Data Encryption Standard): es un algoritmo de cifrado simétrico obsoleto (clave de 56 bits, roto por fuerza bruta).

• 3DES (Triple DES): el término "triple" significa que pasa los datos tres veces por el algoritmo DES original con claves diferentes, aumentando la longitud efectiva de clave. También se considera heredado y en retirada.

• En SSL/TLS modernos el cifrado simétrico de sesión emplea algoritmos como AES.

Certificados SSL/TLS y HTTPS

Un certificado SSL es un archivo que contiene información sobre la identidad del sitio web y su clave pública, firmado por una Autoridad de Certificación (CA) como DigiCert, cuya función es actuar como CA de confianza que permite agregar cifrado a las transacciones web. El certificado sigue el estándar X.509.

• HTTPS necesita un certificado SSL: para que una web utilice el protocolo HTTPS es necesario disponer de un certificado SSL.

• Para establecer la conexión segura HTTPS, el navegador necesita la clave pública del certificado del sitio web, con la que cifra la clave de sesión y establece la comunicación segura con el servidor.

• Un certificado SSL autofirmado es un certificado emitido por el propietario del sitio web (no por una CA de confianza), por lo que el navegador no lo reconoce como fiable.

• Los certificados SSL de pago suelen durar un año (la duración máxima admitida por el ecosistema se ha ido acortando con el tiempo).

• Un certificado SSL cifra toda la información que entra y sale de la página web, protegiéndola frente a interceptación. No tener certificado implica exponer los datos y perder confianza/SEO.

Seguridad del correo electrónico

Además de SSL/TLS para el transporte, en el correo electrónico el estándar S/MIME (Secure/Multipurpose Internet Mail Extensions) es ampliamente utilizado para agregar una capa adicional de seguridad, aportando cifrado y firma digital de los mensajes de extremo a extremo mediante certificados X.509.

Fuentes

• IETF — RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: https://datatracker.ietf.org/doc/html/rfc8446

• IETF — RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2: https://datatracker.ietf.org/doc/html/rfc5246

• IETF — RFC 2246, The TLS Protocol Version 1.0 (1999): https://datatracker.ietf.org/doc/html/rfc2246

• IETF — RFC 6101, The Secure Sockets Layer (SSL) Protocol Version 3.0: https://datatracker.ietf.org/doc/html/rfc6101

• IETF — RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280

• IETF — RFC 8551, S/MIME 4.0 Message Specification: https://datatracker.ietf.org/doc/html/rfc8551

• NIST — FIPS 46-3 / SP 800-67, Data Encryption Standard (DES) y Triple DES (TDEA): https://csrc.nist.gov/pubs/sp/800/67/r2/final

• Wikipedia (referencia histórica cruzada con RFCs) — Transport Layer Security: https://en.wikipedia.org/wiki/Transport_Layer_Security