Internet: arquitectura de red. Origen, evolución y estado actual. Principales servicios. Protocolos HTTP, HTTPS y SSL/TLS.

Índice

1. Por qué este tema se estudia con el navegador abierto
2. Origen y evolución de Internet
3. La arquitectura real de Internet
4. Quién manda en Internet: organismos y estándares
5. El marco jurídico español de Internet
6. Los principales servicios de Internet
7. HTTP: cómo funciona por dentro
8. Métodos HTTP: seguros e idempotentes
9. Códigos de estado
10. Cabeceras y negociación de contenido
11. Cookies, sesiones y tokens
12. HTTP/1.1, HTTP/2 y HTTP/3
13. SSL/TLS: versiones y handshake
14. Certificados y cadena de confianza
15. HTTPS en producción y lo que recomienda el CCN
16. Seguridad de aplicaciones web y OWASP
17. CORS y las cabeceras de seguridad
18. Proxy, CDN, WAF y publicación de servicios
19. Autenticación y autorización en la web
20. Caché y rendimiento
21. Comunicación en tiempo real y otros estilos de servicio
22. El correo en Internet: SPF, DKIM y DMARC
23. Diseño y consumo de una API REST
24. Cuadros para memorizar
25. Los errores que más caen
26. Lo que ya ha preguntado el tribunal
27. Autoevaluación

1. Por qué este tema se estudia con el navegador abierto

Este tema aporta 85 preguntas del corpus oficial, y es el segundo del bloque IV por volumen, detrás del de TCP/IP. Pero su forma es muy distinta a la de los demás: aquí el tribunal no pregunta arquitectura, pregunta el detalle exacto de un protocolo que el opositor usa todos los días sin mirarlo.

Medido sobre el corpus, las cuatro familias que se repiten:

• Códigos de estado HTTP: qué devuelve un servicio REST al crear un recurso (201), qué código corresponde a un usuario sin autorización (403), cuál se usa al superar un límite de peticiones (429), cuál indica servicio no disponible (503) y qué significa la familia 3xx y la 4xx. Cinco preguntas solo de esto.
• Atributos de seguridad de las cookies: cuál impide que el código de la página lea la cookie (HttpOnly) y cuál hace que solo se envíe si se originó en el mismo sitio (SameSite). Cayó en dos convocatorias con las dos preguntas casi calcadas.
• TLS por dentro: qué mensaje contesta el servidor a un ClientHello, qué ventaja tiene la versión 1.3 sobre la 1.2, cuál es la versión mínima aceptable según el CCN y qué parte del certificado usa el navegador.
• Cabeceras y mecanismos de protección: qué cabecera evita el rastreo de tipo MIME, qué hay que configurar para restringir peticiones de origen cruzado, qué módulo filtra tráfico HTTP hacia los servidores web y qué recomienda OWASP contra el XSS.

Y una advertencia de alcance: el epígrafe oficial dice «Internet: arquitectura de red. Origen, evolución y estado actual. Principales servicios. Protocolos HTTP, HTTPS y SSL/TLS», pero el peso de las preguntas está en la segunda mitad. La parte histórica y de organismos aporta una pregunta por examen; HTTP y TLS aportan el resto. Conviene repartir el estudio en esa proporción y no al revés.

2. Origen y evolución de Internet

La historia se pregunta poco, pero cuando cae se pregunta por hitos con fecha, así que conviene tener la secuencia ordenada y no la anécdota.

De ARPANET a Internet

• 1969 · ARPANET: la Agencia de Proyectos de Investigación Avanzada del Departamento de Defensa estadounidense conecta cuatro nodos universitarios. Su aportación conceptual es la conmutación de paquetes, frente a la conmutación de circuitos de la red telefónica, y una red sin centro que sobreviva a la pérdida de nodos.
• 1974: Cerf y Kahn publican el diseño del protocolo de control de transmisión, del que saldrán TCP e IP como protocolos separados.
• 1 de enero de 1983: ARPANET conmuta a TCP/IP y abandona el protocolo anterior. Es la fecha que suele darse como nacimiento técnico de Internet.
• 1984: aparece el DNS, que sustituye al fichero único de nombres de equipos que se distribuía a mano.
• 1986 · NSFNET: la Fundación Nacional para la Ciencia construye la red troncal que interconecta centros de investigación y desplaza a ARPANET, que se desmantela en 1990.
• 1989-1991 · la web: Tim Berners-Lee, en el CERN, propone la World Wide Web y desarrolla sus tres piezas: HTML como lenguaje de marcado, HTTP como protocolo de transferencia y la URL como forma de localizar recursos. El primer sitio web se publica en 1991, y en 1993 el CERN libera la tecnología sin patentes ni cánones.
• 1993 · Mosaic: el navegador gráfico que populariza la web fuera del mundo académico.
• 1990-1995: la troncal se privatiza y se permite el tráfico comercial. Internet deja de ser una red de investigación.

En España, la conexión académica se articula a través de RedIRIS, creada en 1988 y hoy gestionada por el Ministerio de Ciencia a través de la entidad pública Red.es; el dominio de primer nivel .es lo administra Red.es, y el principal punto neutro de intercambio de tráfico es ESPANIX, en Madrid.

Las etapas de la web

Una clasificación que aparece en enunciados como contexto:

• Web 1.0: páginas estáticas, lectura y poco más. El usuario consume.
• Web 2.0: el usuario produce contenido —blogs, redes sociales, wikis—, aparecen las aplicaciones enriquecidas y las interfaces de programación públicas.
• Web 3.0: dos sentidos distintos que conviene no mezclar. El original de Berners-Lee es la web semántica, con datos enlazados, RDF, OWL y SPARQL; el uso más reciente del sector alude a la web descentralizada apoyada en cadenas de bloques.

El estado actual, en términos técnicos

Lo que define el momento presente de Internet, y sí se pregunta de forma indirecta, son cuatro transiciones simultáneas:

• El agotamiento de IPv4 y la migración a IPv6, con doble pila, túneles y la traducción a escala de operador —el CG-NAT— como parche mayoritario.
• El cifrado por defecto: el tráfico web sin cifrar es hoy la excepción, y los navegadores lo marcan como no seguro.
• La concentración en grandes plataformas y en redes de distribución de contenido, que acercan el contenido al usuario y cambian la topología: buena parte del tráfico ya no cruza la red hasta un servidor remoto.
• El desplazamiento del transporte: primero HTTP/2 sobre el transporte fiable y después HTTP/3 sobre QUIC, que viaja sobre datagramas.

3. La arquitectura real de Internet

Internet no es una red, sino una red de redes: un conjunto de redes autónomas que acuerdan interconectarse y encaminar tráfico ajeno usando un protocolo común.

Sistemas autónomos y su interconexión

La unidad de la arquitectura es el sistema autónomo: un conjunto de redes con una política de encaminamiento única, identificado por un número que asignan los registros regionales. Entre sistemas autónomos habla un único protocolo, BGP-4, que no busca el camino más corto en saltos sino el que cumple las políticas comerciales de cada parte.

Esas políticas se materializan en dos tipos de relación que conviene distinguir:

• Tránsito: un operador paga a otro mayor para que le lleve el tráfico a cualquier destino. Los operadores que no pagan tránsito a nadie forman el llamado nivel 1.
• Interconexión directa: dos redes intercambian entre sí el tráfico de sus clientes, normalmente sin cobrarse. Se hace en los puntos neutros de intercambio, que son conmutadores compartidos donde se conectan decenas de redes; el español es ESPANIX.

Direcciones, nombres y recursos

La arquitectura descansa en tres espacios de identificadores que se reparten jerárquicamente: las direcciones IP, los números de sistema autónomo y los nombres de dominio. Los tres los coordina en última instancia la función IANA, dentro de la ICANN, que delega en los cinco registros regionales —a España le corresponde RIPE NCC— y en los registros de cada dominio de primer nivel.

Un recurso concreto se localiza con una URL, que es un tipo de URI. Sus partes se preguntan por su nombre: esquema (https), autoridad (usuario, servidor y puerto), ruta, consulta tras el signo de interrogación y fragmento tras la almohadilla. El fragmento tiene una peculiaridad útil: no viaja al servidor, lo resuelve el navegador.

Redes de distribución de contenido y computación en nube

Una red de distribución de contenido replica los recursos estáticos en servidores repartidos geográficamente y sirve al usuario desde el más cercano, lo que reduce la latencia y absorbe picos de demanda. La elección del nodo se hace con DNS, con anycast o con ambos.

La computación en nube se clasifica por el nivel de servicio, y esa clasificación se pregunta: IaaS entrega infraestructura —máquinas, red y almacenamiento—; PaaS entrega una plataforma de ejecución; SaaS entrega la aplicación terminada. A ellas se añade la función sin servidor, donde se despliega código y el proveedor gestiona todo lo demás.

4. Quién manda en Internet: organismos y estándares

Aquí el tribunal pregunta por atribución: dado un organismo, qué le corresponde. La tabla resuelve las cuatro preguntas del corpus.

Organismo	Qué hace
IETF	Crea los estándares de Internet y los publica como RFC. Trabaja por grupos de trabajo abiertos y por consenso aproximado.
IAB	Supervisa la arquitectura de Internet y el proceso de estandarización.
IRTF	Investigación a largo plazo, lo que todavía no está listo para normalizar.
ICANN / IANA	Coordina los identificadores: nombres de dominio, direcciones y números de protocolo y de puerto.
RIR (RIPE NCC)	Reparto regional de direcciones y de números de sistema autónomo.
W3C	Normaliza las tecnologías de la web: HTML, CSS, XML, WSDL, accesibilidad con las pautas WCAG.
ITU	Organismo de la ONU especializado en telecomunicaciones, que regula el sector a escala internacional entre administraciones y operadores. Su rama ITU-T publica recomendaciones como la X.509.
ISO / IEC	Normalización general, incluido el modelo OSI y la familia 27000.
IEEE	Normas de las redes locales y de los medios: la familia 802.
ETSI	Normalización europea de telecomunicaciones.
OASIS	Estándares de interoperabilidad como SAML o UDDI.

Cómo nace una RFC

Conviene conocer el recorrido porque explica las citas que aparecen en los enunciados. Un documento empieza como borrador de Internet, y si el grupo de trabajo alcanza consenso pasa a norma propuesta; con implantación y experiencia suficientes puede llegar a norma de Internet, y entonces recibe además un número STD. Existen también las series BCP, de mejores prácticas, y las categorías informativa y experimental.

Dos consecuencias prácticas: una RFC nunca se modifica —se publica otra que la actualiza o la deja obsoleta, y el número viejo queda como registro histórico—, y por eso hay que comprobar siempre si la RFC que trae un manual sigue vigente. El ejemplo que más caro sale hoy está en el apartado 13.

5. El marco jurídico español de Internet

El bloque IV es técnico, pero el tribunal ha colado tres preguntas jurídicas dentro de esta materia, así que conviene tenerlas cubiertas.

Los derechos digitales de la LOPDGDD

La Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales, dedica su título X a los derechos digitales, y de ahí salen dos respuestas literales:

• Artículo 79: los derechos y libertades consagrados en la Constitución y en los tratados y convenios internacionales son plenamente aplicables en Internet, y los prestadores de servicios de la sociedad de la información y los proveedores de servicios de Internet contribuirán a garantizarlos.
• Artículo 88, derecho a la desconexión digital: los trabajadores y los empleados públicos tendrán derecho a la desconexión digital para garantizar, fuera del tiempo de trabajo legal o convencionalmente establecido, el respeto de su tiempo de descanso, permisos y vacaciones, así como de su intimidad personal y familiar.

El título X incluye además el derecho a la neutralidad de Internet (art. 80), el acceso universal (81), la seguridad digital (82), la educación digital (83), la protección de menores (84), la rectificación y actualización en Internet (85 y 86), la intimidad frente al uso de dispositivos en el trabajo (87) y frente a la videovigilancia y la geolocalización (89 y 90), y el testamento digital (96).

La actuación electrónica de las administraciones

El Real Decreto 203/2021, de 30 de marzo, aprueba el Reglamento de actuación y funcionamiento del sector público por medios electrónicos. Su artículo 4 enumera los canales de asistencia para el acceso a los servicios electrónicos, y esa lista se preguntó en negativo: son las oficinas de asistencia en materia de registros, el teléfono y el correo electrónico, además de las sedes electrónicas y sedes asociadas. La cita previa no es un canal de asistencia: es un mecanismo de organización de la atención presencial.

Los otros textos que conviene saber citar

• Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico: régimen de los prestadores, comunicaciones comerciales, contratación por vía electrónica y responsabilidad de los intermediarios.
• Ley 11/2022, General de Telecomunicaciones, que sustituyó a la Ley 9/2014 y traspuso el Código Europeo de las Comunicaciones Electrónicas.
• Reglamento (UE) 2022/2065, de servicios digitales, y Reglamento (UE) 2022/1925, de mercados digitales.
• Real Decreto 311/2022, del Esquema Nacional de Seguridad, cuyas medidas de protección de las comunicaciones y de los servicios se aplican a todo lo que se publica en Internet.

6. Los principales servicios de Internet

El epígrafe pide los servicios, y el tribunal los pregunta por su protocolo o por su puerto más que por su descripción. El repaso, con lo que cae de cada uno:

Servicio	Protocolos	Lo que se pregunta
Web	HTTP, HTTPS	Todo el apartado 7 y siguientes
Resolución de nombres	DNS, DoT, DoH	Registros, caché y su papel en el pharming
Correo	SMTP, POP3, IMAP	Puertos seguros: 995, 465 y 993
Transferencia de ficheros	FTP, FTPS, SFTP	La comparación entre los dos seguros
Acceso remoto	SSH, RDP	Puerto 22 para sesión y copia
Voz y vídeo	SIP, RTP, WebRTC	Puerto 5060 y el problema del NAT
Mensajería y presencia	XMPP, MQTT	MQTT en el internet de las cosas
Impresión en red	IPP	Es una colección de estándares abiertos que define un protocolo de impresión en red de alto nivel; viaja sobre HTTP y usa el puerto 631
Sincronización horaria	NTP	Puerto 123
Directorio	LDAP, LDAPS	Puertos 389 y 636
Calidad de servicio	RSVP	Definido en la RFC 2205, es un protocolo de reserva de recursos para los servicios integrados de Internet: el receptor pide la reserva y esta se establece salto a salto

De los servicios de aplicación conviene además saber encuadrar los servicios web, que son la forma en que las aplicaciones se hablan entre sí por Internet. Los dos estilos y su vocabulario:

• REST es un conjunto de principios arquitectónicos, no un protocolo: recursos identificados por URI, verbos de HTTP, representaciones intercambiables y, sobre todo, el servicio no guarda el estado del cliente entre peticiones. Encaja con aplicaciones móviles y servicios ligeros.
• SOAP sí es un protocolo de mensajería con sobre y reglas de codificación en XML, descrito con WSDL y, en su día, publicado en registros UDDI. Ese detalle es una trampa recurrente: UDDI no es una característica de REST, sino del mundo SOAP, y fue la opción falsa de una pregunta.

7. HTTP: cómo funciona por dentro

HTTP es un protocolo de petición y respuesta, de texto en su versión clásica y binario desde la 2, que funciona sin estado: cada petición se atiende sin memoria de las anteriores. Todo lo que parece memoria —estar identificado, tener un carrito— se consigue con cookies o con tokens, que es justo lo que se pregunta en el apartado 11.

La familia de documentos que lo define se renovó por completo en 2022 y conviene citarla bien, porque los manuales antiguos siguen apuntando a las RFC 7230 a 7235, que están obsoletas:

Documento	Qué define
RFC 9110 (STD 97)	Semántica común a todas las versiones: métodos, códigos de estado, cabeceras, negociación y autenticación
RFC 9111	Caché
RFC 9112	HTTP/1.1: la sintaxis de los mensajes de texto
RFC 9113	HTTP/2: binario y multiplexado
RFC 9114	HTTP/3: sobre QUIC, y por tanto sobre datagramas
RFC 9204	QPACK, la compresión de cabeceras de HTTP/3

Anatomía de un mensaje

Una petición tiene tres partes: la línea inicial con el método, el objetivo y la versión; las cabeceras, una por línea; y un cuerpo opcional, separado de las cabeceras por una línea en blanco. Una respuesta tiene la misma estructura, con la línea inicial formada por la versión, el código de estado de tres dígitos y su frase explicativa.

El recorrido completo de una petición, que conviene tener en la cabeza porque explica casi todos los fallos de producción: resolución del nombre por DNS, apertura de la conexión de transporte, acuerdo TLS si el esquema es seguro, envío de la petición, proceso en el servidor —muchas veces atravesando un proxy inverso, una caché o un cortafuegos de aplicación—, respuesta, y cierre o reutilización de la conexión.

8. Métodos HTTP: seguros e idempotentes

Aquí hay una pregunta que se falla mucho porque mezcla dos propiedades que no son lo mismo:

• Seguro: el método no pretende modificar el estado del servidor. Solo lee.
• Idempotente: repetir la misma petición varias veces deja el servidor en el mismo estado que ejecutarla una sola vez. Puede modificar, pero repetirlo no añade efectos.

Todo método seguro es idempotente; el recíproco no se cumple, y ahí está la pregunta.

Método	Seguro	Idempotente	Cuerpo	Para qué
GET	Sí	Sí	No	Obtener una representación del recurso
HEAD	Sí	Sí	No	Como GET pero solo cabeceras
OPTIONS	Sí	Sí	No	Qué admite el recurso; sostiene el preámbulo de CORS
TRACE	Sí	Sí	No	Eco de la petición; se desactiva por seguridad
PUT	No	Sí	Sí	Sustituir por completo el recurso en una URI conocida
DELETE	No	Sí	No	Borrar el recurso
POST	No	No	Sí	Crear un recurso subordinado o procesar datos
PATCH	No	No	Sí	Modificación parcial

9. Códigos de estado

Las cinco familias, con su significado exacto:

Familia	Significado
1xx	Informativo: la petición se ha recibido y el proceso continúa
2xx	Éxito: recibida, entendida y aceptada
3xx	Redirección: el cliente tiene que tomar una acción adicional para completar la petición
4xx	Error del cliente: la petición tiene mala sintaxis o no puede atenderse
5xx	Error del servidor: la petición es válida pero el servidor falla

Y los códigos concretos que el tribunal ha preguntado o puede preguntar, que son los que hay que memorizar uno a uno:

Código	Nombre	Cuándo se devuelve
200	OK	Éxito con cuerpo de respuesta
201	Created	Se ha creado un recurso nuevo: es el que debe devolver un servicio REST tras un POST que crea, con la cabecera Location apuntando al recurso
202	Accepted	Aceptada para proceso asíncrono, todavía sin completar
204	No Content	Éxito sin cuerpo; típico de un DELETE o un PUT
301 / 308	Moved Permanently	Redirección permanente; el 308 conserva el método
302 / 307	Found	Redirección temporal; el 307 conserva el método
304	Not Modified	La copia en caché del cliente sigue válida
400	Bad Request	Petición mal formada
401	Unauthorized	No autenticado: falta credencial o es inválida
403	Forbidden	Autenticado pero SIN AUTORIZACIÓN para ese recurso. Es la pareja que se confunde con el 401
404	Not Found	El recurso no existe
405	Method Not Allowed	El recurso existe pero no admite ese método
409	Conflict	Conflicto con el estado actual del recurso
415	Unsupported Media Type	Tipo de contenido no admitido
429	Too Many Requests	Se ha superado el límite de peticiones en un periodo: es el código del control de tasa contra la denegación de servicio
500	Internal Server Error	Fallo genérico del servidor
502	Bad Gateway	Un intermediario recibe una respuesta inválida del servidor de origen
503	Service Unavailable	El servicio no está disponible: sobrecarga o mantenimiento. Admite la cabecera Retry-After
504	Gateway Timeout	El intermediario no recibe respuesta a tiempo

10. Cabeceras y negociación de contenido

Las cabeceras son pares de nombre y valor que acompañan al mensaje. Las que importan, agrupadas por función:

Cabecera	Sentido	Para qué sirve
Host	Petición	Servidor solicitado; obligatoria desde HTTP/1.1 y lo que permite alojar varios sitios en una IP
User-Agent	Petición	Identifica al cliente
Accept, Accept-Language, Accept-Encoding	Petición	Negociación de contenido: tipo, idioma y compresión que el cliente admite
Authorization	Petición	Credencial. Con el esquema Bearer transporta un token: si su valor son tres bloques separados por puntos, es un JWT
Cookie	Petición	Devuelve al servidor las cookies que este fijó
Referer	Petición	Página de procedencia; se controla con Referrer-Policy
If-None-Match, If-Modified-Since	Petición	Peticiones condicionales que permiten el 304
Content-Type	Ambos	Tipo de medio del cuerpo
Content-Length	Ambos	Tamaño del cuerpo en bytes
Location	Respuesta	Destino de una redirección o URI del recurso creado
Set-Cookie	Respuesta	Fija una cookie con sus atributos
Cache-Control, ETag, Expires	Respuesta	Política de caché y validación
Retry-After	Respuesta	Cuándo reintentar; acompaña al 429 y al 503
WWW-Authenticate	Respuesta	Esquema de autenticación exigido; acompaña al 401

La negociación de contenido es el mecanismo por el que cliente y servidor acuerdan la representación: el cliente expresa preferencias con las cabeceras Accept y sus factores de calidad, y el servidor elige y lo declara con Content-Type y Content-Language, añadiendo Vary para que las cachés no sirvan la variante equivocada.

11. Cookies, sesiones y tokens

Como HTTP no tiene estado, la sesión se sostiene con una cookie que el servidor fija con Set-Cookie y el navegador devuelve en cada petición al mismo sitio. Sus atributos de seguridad son la materia que más se ha preguntado de este tema:

Atributo	Qué hace
HttpOnly	Impide que los scripts del lado del cliente accedan a la cookie, de modo que un XSS no puede robarla. Es decir: JavaScript no la ve
SameSite	Controla el envío en peticiones de terceros sitios: con Strict solo se envía si la cookie se originó en el mismo sitio al que se contacta; con Lax se admite además la navegación de nivel superior; con None se envía siempre y exige Secure. Es la defensa de fondo contra el CSRF
Secure	Solo se transmite por conexiones cifradas
Domain y Path	Ámbito de la cookie: a qué dominios y rutas se manda
Expires y Max-Age	Caducidad. Sin ellos, la cookie es de sesión y muere al cerrar el navegador

Tokens: el JWT

Las interfaces de programación modernas prefieren no guardar sesión en el servidor y viajar con un token firmado. El formato habitual es el JWT, que llega en la cabecera Authorization con el esquema Bearer y se reconoce a simple vista: tres bloques codificados en base64url separados por puntos —cabecera, carga útil y firma—.

Tres cautelas que conviene saber: el token va firmado, no cifrado, así que su contenido es legible por quien lo tenga y no debe llevar datos sensibles; quien lo posee puede usarlo, de modo que debe viajar siempre por canal cifrado y con caducidad corta; y la validación del servidor debe comprobar el algoritmo esperado, porque aceptar el que diga la cabecera del propio token es una vulnerabilidad clásica.

12. HTTP/1.1, HTTP/2 y HTTP/3

	HTTP/1.1	HTTP/2	HTTP/3
Documento	RFC 9112	RFC 9113	RFC 9114
Formato	Texto	Binario, en tramas	Binario, en tramas
Transporte	TCP	TCP	QUIC, sobre UDP
Concurrencia	Una petición por conexión, con persistencia y encadenado poco usado	Multiplexación de flujos en una conexión	Multiplexación sin bloqueo de cabecera de línea en el transporte
Compresión de cabeceras	No	HPACK	QPACK
Cifrado	Opcional	Opcional, en la práctica siempre con TLS	Obligatorio, integrado en QUIC

El problema que explica la evolución es el bloqueo de cabecera de línea. En la versión 1.1, una respuesta lenta retiene a las que van detrás en esa conexión, y por eso los navegadores abrían seis conexiones por servidor. La versión 2 lo resuelve en el protocolo, multiplexando flujos, pero lo hereda del transporte: si se pierde un segmento, el transporte fiable retiene todos los flujos hasta recuperarlo. La versión 3 lo resuelve bajando al transporte, con flujos independientes dentro de QUIC.

Otros rasgos de QUIC que conviene conocer: establecimiento en una sola vuelta —o ninguna al reanudar—, porque integra el acuerdo criptográfico; migración de conexión, que permite cambiar de red sin cortar la sesión; y control de congestión en espacio de usuario, lo que acelera su evolución. Su contrapartida: viaja por el 443 en datagramas, y hay cortafuegos que lo bloquean, en cuyo caso el cliente vuelve a la versión 2.

13. SSL/TLS: versiones y handshake

TLS es el protocolo que aporta confidencialidad, integridad y autenticación del servidor a cualquier protocolo de aplicación. Se sitúa entre el transporte y la aplicación, y por eso las redes privadas virtuales que se apoyan en él se llaman de nivel de transporte. Cuando HTTP viaja sobre él se llama HTTPS.

El árbol genealógico, con lo que está prohibido

Versión	Año	Estado
SSL 2.0	1995	Prohibido, roto
SSL 3.0	1996	Prohibido: la RFC 7568 lo declaró obsoleto tras el ataque POODLE
TLS 1.0	1999	Obsoleto por la RFC 8996
TLS 1.1	2006	Obsoleto por la RFC 8996
TLS 1.2	2008	Vigente, es el mínimo aceptable
TLS 1.3	2018	Vigente y recomendado; es la última versión estable

El acuerdo inicial, mensaje a mensaje

El handshake negocia la versión y los algoritmos, autentica al servidor y establece las claves de sesión. En TLS 1.2, simplificado:

1. ClientHello: el cliente propone versiones, suites de cifrado, extensiones —entre ellas SNI, el nombre del servidor que busca— y un valor aleatorio.
2. ServerHello: el servidor acepta los parámetros y responde con su elección de versión y suite, más su propio valor aleatorio. Esta es la respuesta literal de una pregunta del corpus: recibido el ClientHello y aceptados los parámetros, lo que ocurre es que el servidor manda el ServerHello.
3. Certificate y, según la suite, ServerKeyExchange, con el material para el intercambio de claves; opcionalmente CertificateRequest si se exige certificado de cliente.
4. ServerHelloDone, y el cliente responde con su parte del intercambio de claves.
5. ChangeCipherSpec y Finished en ambos sentidos: desde ahí todo va cifrado.

En TLS 1.3 el proceso se comprime: el cliente envía ya en el ClientHello su aportación al intercambio de claves con la extensión key_share, y el servidor contesta con ServerHello, los parámetros cifrados, su certificado y Finished. Resultado: el acuerdo se completa en un solo viaje de ida y vuelta, con un modo de reanudación de cero vueltas para sesiones ya conocidas.

Qué mejora exactamente la versión 1.3

• Menos latencia: una vuelta en lugar de dos.
• Menos superficie de ataque: se eliminan RC4, 3DES, MD5, SHA-1, la compresión, la renegociación y el intercambio de claves con RSA estático.
• Secreto hacia adelante obligatorio: las claves de sesión son efímeras, así que comprometer la clave del servidor no descifra el tráfico grabado antes.
• Más partes cifradas del propio acuerdo, incluida la del certificado.

Lo que no hace, y son los distractores típicos: no prescinde de los certificados, no añade pasos de verificación para alargar la clave y no comprime los datos, precisamente porque la compresión resultó explotable.

Dos extensiones recientes que conviene conocer: el Encrypted Client Hello, que cifra el nombre del servidor solicitado y cierra la última fuga de metadatos del acuerdo, y los mecanismos híbridos post-cuánticos de intercambio de claves, que combinan un algoritmo clásico con uno resistente a la computación cuántica.

Qué es una suite de cifrado y por qué cambió en la versión 1.3

Lo que de verdad se negocia en el acuerdo es la suite de cifrado: el conjunto de algoritmos que se van a usar. En TLS 1.2 una suite nombra cuatro cosas a la vez —intercambio de claves, autenticación, cifrado simétrico y función de resumen—, y de ahí esos nombres largos con cuatro siglas encadenadas. En TLS 1.3 la suite se reduce a dos elementos, el cifrado autenticado con datos asociados y la función de resumen, porque el intercambio de claves y la autenticación se negocian por separado en extensiones propias. Esa simplificación es la que permitió retirar de golpe las combinaciones inseguras.

Los cuatro componentes, con lo que hoy se considera aceptable:

• Intercambio de claves: efímero sobre curvas elípticas, que es lo que da el secreto hacia adelante. El intercambio con clave RSA estática está retirado precisamente porque no lo da.
• Autenticación del servidor: firma con la clave del certificado, sea RSA o de curva elíptica.
• Cifrado simétrico: modos autenticados como AES en GCM, AES en CCM o ChaCha20-Poly1305. Los modos de cifrado por bloques en cadena y los cifradores de flujo antiguos están descartados.
• Resumen: SHA-256 o superior. MD5 y SHA-1 no se admiten.

Un detalle de examen: el orden de preferencia lo debe imponer el servidor, no el cliente, para que un cliente antiguo o manipulado no arrastre la conexión a la combinación más débil de las que ambos admiten.

14. Certificados y cadena de confianza

Un certificado es un documento firmado por una autoridad de certificación que vincula una identidad con una clave pública. El formato es X.509, recomendación de la ITU-T, y sus campos se preguntan:

• Versión y número de serie.
• Emisor: la autoridad que lo firma.
• Sujeto: a quién identifica, con el nombre común del servidor.
• Periodo de validez: no antes de, no después de.
• Clave pública del sujeto y algoritmo asociado.
• Extensiones: uso de la clave, nombres alternativos del sujeto —que es el campo que de verdad valida el navegador—, puntos de distribución de listas de revocación y acceso a la información de la autoridad.
• Firma de la autoridad emisora.

La cadena y su revocación

La confianza es jerárquica: el certificado del servidor lo firma una autoridad intermedia, y a esta la firma una raíz que viene preinstalada en el sistema operativo o el navegador. El servidor debe enviar su certificado y los intermedios; si se olvida alguno, unos clientes funcionan y otros no, que es el fallo de configuración más común y el que explica los avisos intermitentes.

La revocación antes del vencimiento se comprueba con listas de revocación (CRL) o con el protocolo de estado en línea (OCSP), que admite además la grapa: el propio servidor adjunta una respuesta firmada y reciente, lo que evita que el cliente delate al emisor qué sitio está visitando.

Por nivel de comprobación, los certificados son de validación de dominio, de organización o extendida; y por alcance, de un nombre, comodín para un nivel de subdominios, o multidominio. En la Administración española el contexto es la Ley 6/2020 y el Reglamento (UE) 910/2014, en su versión revisada por el Reglamento 2024/1183, con los certificados de sede electrónica y de sello electrónico como piezas propias.

15. HTTPS en producción y lo que recomienda el CCN

Llevar TLS a producción bien tiene una lista corta de decisiones, y todas han aparecido en el examen o están a un paso de aparecer:

• El puerto 80 se deja abierto y se redirige. La recomendación del Centro Criptológico Nacional es disponer del TCP/80 configurando el servidor para que haga una redirección automática de HTTP a HTTPS, porque quien teclea el dominio sin esquema llega por ahí. Cerrarlo le deja un error de conexión.
• HSTS: la cabecera Strict-Transport-Security ordena al navegador usar solo HTTPS para ese dominio durante el tiempo indicado, lo que cierra la ventana de la primera petición en claro. Con la directiva de precarga, el dominio entra en la lista que traen los navegadores de fábrica.
• Versión mínima 1.2 y recomendada 1.3, con suites de cifrado que garanticen secreto hacia adelante y sin los algoritmos retirados.
• Terminación: es habitual que TLS termine en un balanceador o proxy inverso. Entonces hay que decidir si el tramo interno va cifrado, y el cortafuegos de aplicación debe inspeccionar después de descifrar, no antes.
• Autenticación mutua: si se exige certificado también al cliente, se habla de TLS mutuo; es lo habitual entre servicios y en integraciones administrativas.
• Automatización de la renovación, porque el motivo más frecuente de caída de un sitio seguro es un certificado caducado.

16. Seguridad de aplicaciones web y OWASP

El OWASP Top 10 es el documento de referencia sobre los riesgos más críticos de las aplicaciones web. Su edición vigente es la de 2025, publicada en su versión final a comienzos de 2026, y sustituye a la de 2021 que todavía citan casi todos los manuales:

Código	Categoría
A01:2025	Broken Access Control — control de acceso roto, que absorbe la falsificación de peticiones del lado del servidor
A02:2025	Security Misconfiguration — configuración insegura
A03:2025	Software Supply Chain Failures — fallos de la cadena de suministro, categoría nueva que amplía la de componentes vulnerables
A04:2025	Cryptographic Failures — fallos criptográficos
A05:2025	Injection — inyección, que incluye el XSS
A06:2025	Insecure Design — diseño inseguro
A07:2025	Authentication Failures — fallos de autenticación
A08:2025	Software or Data Integrity Failures — fallos de integridad
A09:2025	Security Logging and Alerting Failures — fallos de registro y alerta
A10:2025	Mishandling of Exceptional Conditions — gestión deficiente de condiciones excepcionales, la otra categoría nueva

Los ataques concretos y su defensa

• XSS, ejecución de código en el navegador de la víctima. Tiene tres formas: almacenado —el código queda guardado en el servidor—, reflejado —viaja en la petición y se devuelve en la respuesta— y basado en el modelo de objetos del documento, que ocurre entero en el cliente. La recomendación de OWASP, que fue respuesta literal, es validar y escapar correctamente los datos antes de mostrarlos en el navegador, es decir, codificar la salida según el contexto; se refuerza con HttpOnly y con una política de seguridad de contenido.
• Inyección SQL: se previene con consultas preparadas y parámetros, no concatenando cadenas ni filtrando comillas.
• CSRF: se aprovecha de que el navegador manda las cookies solas. Se ataja con testigos anti-CSRF por formulario y con SameSite.
• SSRF: se engaña al servidor para que pida recursos internos. Se limita con listas de destinos permitidos y sin seguir redirecciones a ciegas.
• Clickjacking: se evita impidiendo el enmarcado con X-Frame-Options o con la directiva de antecesores de marco.
• Denegación de servicio por volumen de peticiones: control de tasa, y el cliente que se pasa recibe un 429.

17. CORS y las cabeceras de seguridad

La política del mismo origen es la regla base del navegador: el código de una página solo puede leer respuestas de su mismo origen, entendido como la terna esquema, servidor y puerto. Eso protege, pero rompe las arquitecturas donde el frontal y la interfaz de programación viven en dominios distintos.

La solución estándar es CORS, el intercambio de recursos de origen cruzado: el servidor declara con cabeceras quién puede leerle. Fue respuesta literal a la pregunta de qué configurar para restringir que solo se acepten las peticiones de origen cruzado procedentes del frontal.

• Access-Control-Allow-Origin: el origen autorizado. El comodín es incompatible con el envío de credenciales.
• Access-Control-Allow-Methods y Allow-Headers: lo que se permite en la petición.
• Access-Control-Allow-Credentials: permite mandar cookies o credenciales.
• La comprobación previa: para métodos o cabeceras no simples, el navegador manda antes un OPTIONS y solo continúa si la respuesta lo autoriza.

Importante para no confundirse en el examen: CORS relaja una restricción del navegador; no es un cortafuegos. No impide que un programa ajeno llame a la interfaz desde un servidor, porque esa llamada no pasa por la política del mismo origen.

Las cabeceras de respuesta que endurecen el sitio

Cabecera	Qué evita
X-Content-Type-Options: nosniff	El rastreo de tipo MIME: obliga al navegador a respetar el Content-Type declarado en lugar de adivinar el tipo, lo que cierra una vía de XSS. Fue respuesta literal
Content-Security-Policy	Declara de dónde puede cargarse cada tipo de recurso; es la defensa de fondo contra el XSS
Strict-Transport-Security	Conexiones en claro a ese dominio
X-Frame-Options	Que el sitio se muestre dentro de un marco ajeno
Referrer-Policy	Que se filtre la dirección de procedencia a terceros
Permissions-Policy	Uso de cámara, micrófono o geolocalización por parte de la página

18. Proxy, CDN, WAF y publicación de servicios

Entre el navegador y la aplicación hay casi siempre intermediarios, y el tribunal pregunta por su función y por productos concretos.

• Proxy directo: se sitúa del lado del cliente y sale a Internet por él. Sirve para filtrar, registrar y, sobre todo, cachear. El producto que dio por bueno el tribunal como proxy-caché compatible con HTTP, HTTP/2 y HTTPS es SQUID, y esa pregunta cayó en dos convocatorias.
• Proxy inverso: se sitúa delante de los servidores y los representa ante Internet. Termina TLS, reparte carga, sirve contenido estático y oculta la topología interna. Nginx, HAProxy y Apache en modo proxy son los habituales.
• Balanceador de carga: reparte peticiones entre instancias con algoritmos de reparto y comprobaciones de estado, manteniendo o no la afinidad de sesión.
• WAF, cortafuegos de aplicación web: es el módulo que filtra y monitoriza el tráfico HTTP desde Internet hacia los servidores web, y fue respuesta literal. A diferencia de un cortafuegos de red, entiende el protocolo: ve la URL, los parámetros y el cuerpo, y puede bloquear inyecciones o XSS con un conjunto de reglas.
• Red de distribución de contenido: cachea en el borde y absorbe picos y ataques volumétricos.

Monitorización y vigilancia

Para comprobar que todo eso sigue en pie, dos herramientas del corpus. Nagios vigila equipos, servicios y direcciones web, y su configuración se valida antes de recargar con nagios -v /usr/local/nagios/etc/nagios.cfg, que fue respuesta literal. Y en el ámbito público, el CCN-CERT ofrece el sistema de alerta temprana SAT INET para vigilar el tráfico de la conexión a Internet de un organismo: su arquitectura coloca una sonda en la red del organismo y, según la respuesta dada por buena, las comunicaciones con el sistema central se hacen por un túnel cifrado que se inicia desde la sonda hacia el sistema central, no al revés.

19. Autenticación y autorización en la web

El apartado 11 ha dejado a medias una distinción que el tribunal explota: autenticar es comprobar quién eres; autorizar es decidir qué puedes hacer. Los códigos de estado ya separan las dos —401 y 403—, y los mecanismos también.

Los esquemas del propio HTTP

• Basic: usuario y contraseña codificados en base64 en la cabecera Authorization. Codificar no es cifrar: solo es aceptable sobre TLS, y aun así está en retirada.
• Digest: usa un desafío y un resumen para no mandar la contraseña, pero depende de algoritmos antiguos.
• Bearer: el portador del token tiene acceso. Es el esquema de los tokens de acceso, con el JWT como formato mayoritario.
• mTLS: la autenticación la aporta el certificado de cliente en el propio acuerdo TLS, sin credenciales de aplicación. Es lo habitual entre servicios y en integraciones administrativas.

Delegación: OAuth 2.0 y OpenID Connect

Conviene tener clara la división del trabajo, porque se pregunta por confusión entre ambos:

• OAuth 2.0 es un marco de AUTORIZACIÓN: permite que una aplicación acceda a recursos de un usuario en otro servicio sin conocer su contraseña. Sus cuatro papeles son el propietario del recurso, el cliente, el servidor de autorización y el servidor de recursos. El flujo recomendado hoy es el de código de autorización con PKCE; el implícito y el de contraseña están desaconsejados. Lo que entrega es un token de acceso y, opcionalmente, uno de refresco.
• OpenID Connect es la capa de AUTENTICACIÓN construida sobre el anterior: añade un token de identidad en formato JWT y un punto final de información del usuario. Es lo que hay detrás de «entrar con» una cuenta ajena.
• SAML 2.0 resuelve lo mismo en el mundo empresarial con aserciones XML, y es el que sostiene la federación clásica entre administraciones.

En el sector público español la pieza equivalente es Cl@ve, la plataforma de identificación y firma, que admite tanto la identificación con credenciales propias como el certificado electrónico y el DNI electrónico. La autenticación de las sedes ante el ciudadano se apoya, del otro lado, en los certificados de sede electrónica.

Buenas prácticas que se preguntan de refilón

• Doble factor: algo que se sabe, algo que se tiene y algo que se es. El factor por mensaje de texto es el más débil de los aceptables.
• Contraseñas: se guardan con funciones de derivación pensadas para ser lentas —Argon2, scrypt o bcrypt—, con sal, nunca con un resumen simple.
• Gestión de la sesión: identificador nuevo tras iniciar sesión, caducidad por inactividad y cierre efectivo del lado del servidor.
• Claves de programación: identifican a la aplicación, no al usuario, y no sirven como autenticación de personas.

20. Caché y rendimiento

La caché de HTTP es lo que hace que la web sea usable, y su comportamiento se controla con cabeceras. Es materia de examen porque explica los códigos 304 y los fallos de «he actualizado la página y sigo viendo lo viejo».

Quién cachea

Hay tres capas de caché: la privada del navegador, la compartida de los intermediarios —proxy, red de distribución de contenido— y la del propio servidor o su capa de aplicación. La diferencia importa porque una respuesta con datos personales no puede guardarse en una caché compartida, y eso se declara con la directiva private.

Las directivas que hay que reconocer

Directiva de Cache-Control	Qué ordena
max-age	Segundos que la respuesta se considera fresca
s-maxage	Lo mismo, pero solo para cachés compartidas
public / private	Si puede guardarla un intermediario o solo el navegador
no-cache	Puede guardarse, pero hay que revalidar antes de servirla
no-store	No se guarda en ningún sitio: es lo que se pone en respuestas sensibles
must-revalidate	Prohíbe servir una copia caducada aunque el origen no responda
immutable	El recurso no cambiará durante su vida útil

La validación funciona con dos parejas: el ETag de la respuesta se devuelve en la petición siguiente con If-None-Match, y la fecha de Last-Modified se devuelve con If-Modified-Since. Si nada ha cambiado, el servidor contesta 304 Not Modified sin cuerpo, que es la respuesta más barata que existe. Y la cabecera Vary le dice a la caché qué cabeceras de la petición forman parte de la clave, para que no sirva la versión en otro idioma o sin comprimir.

Lo que de verdad acelera un sitio

• Compresión del texto con gzip o, mejor, Brotli, negociada con Accept-Encoding.
• Huella en el nombre del fichero para los recursos estáticos: así pueden cachearse un año y, al cambiar, cambia la dirección.
• Distribución en el borde con una red de contenido, que además reduce la latencia del acuerdo TLS.
• Menos vueltas: multiplexación de HTTP/2 y HTTP/3, y reanudación de sesión en TLS.
• Medición con las métricas de experiencia de usuario que publica la industria —el mayor elemento visible, la estabilidad del diseño y la respuesta a la primera interacción—, que son las que usan los buscadores para valorar la página.

21. Comunicación en tiempo real y otros estilos de servicio

El esquema de petición y respuesta no sirve para todo, y el epígrafe de servicios de Internet incluye lo que lo complementa:

• WebSocket: un canal bidireccional y permanente sobre una conexión que empieza como HTTP y se transforma con la cabecera Upgrade. Sus esquemas son ws y wss, y este último va sobre TLS. Es lo adecuado para chats, pizarras compartidas y paneles en vivo.
• Eventos enviados por el servidor: un flujo unidireccional del servidor al cliente sobre HTTP corriente, más simple que el anterior y con reconexión automática. Vale cuando solo hay que empujar avisos.
• Sondeo largo: la solución antigua, en la que el cliente pregunta y el servidor retiene la respuesta hasta que hay algo. Se sigue usando como reserva.
• Webhooks: la inversión del papel. El servicio ajeno llama a una dirección nuestra cuando ocurre algo, así que hay que verificar la firma de la llamada y hacerla idempotente, porque los reintentos duplican avisos.
• gRPC: llamadas a procedimiento remoto sobre HTTP/2 con mensajes binarios definidos en un fichero de contrato. Rinde más que REST entre servicios y admite flujos en ambos sentidos, a cambio de no ser legible ni nativo en el navegador.
• GraphQL: un único punto final donde el cliente describe los datos que quiere. Evita pedir de más y de menos, y desplaza la complejidad al servidor.

Para el internet de las cosas el protocolo característico es MQTT, de publicación y suscripción a través de un intermediario, con tres niveles de calidad de servicio en la entrega y un consumo mínimo, pensado para enlaces malos y dispositivos con batería.

22. El correo en Internet: SPF, DKIM y DMARC

El correo es el otro gran servicio de Internet, y su problema estructural es que SMTP no autentica al remitente: cualquiera puede escribir en el sobre el nombre que quiera. De ahí los tres mecanismos que se despliegan en el DNS y que conviene distinguir uno de otro:

Mecanismo	Qué comprueba	Dónde vive
SPF	Que el servidor que envía esté autorizado por el dominio del remitente	Registro TXT del dominio
DKIM	Que el mensaje lleve una firma digital válida del dominio y no se haya alterado	Clave pública en un registro TXT del selector
DMARC	Qué hacer si fallan los anteriores y que el dominio del sobre coincida con el visible	Registro TXT con la política: none, quarantine o reject

Los tres son complementarios y ninguno sustituye a los otros: el primero autoriza servidores, el segundo garantiza integridad y autoría, y el tercero es el que decide y el que pide informes. A ellos se añaden el cifrado del transporte con STARTTLS —y su refuerzo MTA-STS, que evita la degradación a texto en claro— y, para el contenido, el cifrado de extremo a extremo con S/MIME o PGP, que es cosa del cliente y no del servidor.

Del lado del usuario, los puertos seguros son los del cuadro del apartado 6 —995, 465 y 993— y la elección entre descarga y sincronización sigue siendo la misma de siempre: quien consulta desde varios dispositivos quiere IMAP.

23. Diseño y consumo de una API REST

En los supuestos prácticos del INAP este tema no se pregunta solo en prosa: se pregunta leyendo código. Dos preguntas de 2026 ponían cuatro fragmentos casi idénticos y había que elegir el que funciona, uno en el servidor y otro en el navegador. Conviene reconocer las piezas.

El lado del servidor

En el marco de trabajo más usado en la Administración para Java, un controlador que expone una colección se escribe con tres anotaciones y nada más: la que declara la clase como controlador de servicios web, la que asocia un método al verbo y a la ruta, y el tipo de retorno, que el marco convierte a JSON por su cuenta.

@RestController
public class AlumnoController {
  @GetMapping("/alumnos")
  public List<Alumno> obtenerAlumnos() {
    return repository.findAll();
  }
}

Los errores que ponen en los distractores son siempre los mismos cuatro, y merece la pena saber identificarlos: usar la anotación de controlador clásico sin indicar que el cuerpo es la respuesta, asociar el método al verbo equivocado —de escritura para una consulta—, devolver el objeto de respuesta sin el tipo adecuado, o colgar la ruta de la clase y del método a la vez y duplicarla.

El lado del cliente

Para consumirla desde el navegador, la forma nativa es la interfaz de recuperación de recursos, que devuelve una promesa. El patrón mínimo tiene dos pasos encadenados: primero se convierte la respuesta al formato que se espera y después se usa el dato.

fetch("http://localhost:8080/alumnos")
  .then(response => response.json())
  .then(data => console.log(data));

La trampa habitual del examen es saltarse la conversión y tratar la respuesta como si ya fuera el dato, o encadenar el manejo del error donde no corresponde. Y el fallo real más frecuente al ejecutarlo no está en el código, sino en el servidor: si el frontal vive en otro origen y la interfaz no declara la cabecera de origen permitido, el navegador bloquea la lectura y la consola avisa de un problema de origen cruzado, aunque la petición haya llegado y el servidor haya contestado.

Las decisiones de diseño que se preguntan

Decisión	Lo que se considera correcto
Nombres de recurso	Sustantivos en plural y en minúscula, sin verbos: la acción la pone el método
Jerarquía	La relación se expresa en la ruta, con el recurso padre delante del hijo
Consultas	Filtros, orden y paginación como parámetros de consulta, no como rutas distintas
Creación	POST a la colección, respuesta 201 con la cabecera Location del recurso nuevo
Sustitución y modificación	PUT sustituye el recurso completo; PATCH cambia una parte
Borrado	DELETE, con 204 cuando no hay nada que devolver
Versionado	En la ruta o mediante negociación de contenido; lo importante es no romper a los clientes existentes
Errores	Código de estado adecuado y cuerpo con detalle legible; el estándar recomendado es el de detalles de problema
Seguridad	TLS siempre, autorización por token, control de tasa con 429 y validación de toda entrada

Dos rasgos de REST que conviene tener claros porque son los que el tribunal usa como afirmación verdadera o falsa. El primero, ya visto: el servidor no guarda el estado del cliente entre peticiones, de modo que cada una llega con todo lo necesario y cualquier instancia puede atenderla —lo que permite escalar horizontalmente—. El segundo, la interfaz uniforme: los recursos se manipulan con los verbos del protocolo y las representaciones son intercambiables, sin inventar operaciones nuevas en la URL.

Y el contraste que cierra el apartado: frente a REST, el estilo de servicios basado en el protocolo de mensajería aporta un contrato formal y una descripción publicable, con su lenguaje de descripción y sus registros de publicación, a cambio de mensajes más pesados y de un acoplamiento mayor. Elegir uno u otro no es cuestión de modernidad: los servicios de interoperabilidad entre administraciones siguen apoyándose en buena medida en el segundo, y el catálogo de servicios comunes los expone así.

24. Cuadros para memorizar

Los códigos que hay que cantar sin pensar

Situación	Código
Un servicio REST crea un recurso tras un POST	201
Operación correcta sin nada que devolver	204
El recurso se ha movido para siempre	301
La copia en caché del cliente sigue siendo válida	304
Falta la credencial o no es válida	401
Hay credencial pero no hay autorización	403
El método no está permitido en ese recurso	405
Se ha superado el límite de peticiones	429
Fallo genérico del servidor	500
El servicio no está disponible	503

Atributos de cookie, uno por defecto

Quiero…	Atributo
Que el código de la página no pueda leerla	HttpOnly
Que no se envíe en peticiones nacidas en otro sitio	SameSite
Que no viaje por conexiones sin cifrar	Secure
Que caduque en una fecha o tras un plazo	Expires o Max-Age

Cada mecanismo con su problema

Problema	Mecanismo
Peticiones del frontal a la interfaz en otro dominio	CORS
Rastreo de tipo MIME	X-Content-Type-Options: nosniff
Filtrar tráfico HTTP hacia los servidores web	WAF
Cachear y acelerar la salida a Internet	Proxy-caché: SQUID
Robo de la cookie de sesión por XSS	HttpOnly y política de seguridad de contenido
Acciones en nombre del usuario desde otro sitio	Testigo anti-CSRF y SameSite
Primera petición en claro antes del salto a HTTPS	HSTS
Abuso por volumen de peticiones	Control de tasa, con respuesta 429

Las cifras y citas del tema

Dato	Valor
Semántica de HTTP	RFC 9110, que es STD 97
HTTP/1.1, HTTP/2 y HTTP/3	RFC 9112, 9113 y 9114
Especificación de TLS 1.3	RFC 9846, que deja obsoleta la RFC 8446
Obsolescencia de TLS 1.0 y 1.1	RFC 8996
Reserva de recursos	RSVP, RFC 2205
Formato de certificado	X.509, recomendación de la ITU-T
Edición vigente del OWASP Top 10	La de 2025
Derechos digitales y desconexión digital	LO 3/2018, arts. 79 y 88
Canales de asistencia electrónica	RD 203/2021, art. 4
Puertos: HTTP, HTTPS, IPP	80, 443 y 631

25. Los errores que más caen

• Confundir 401 con 403. El 401 es «no sé quién eres»; el 403, «sé quién eres y no puedes». La pregunta por la falta de autorización es el 403.
• Creer que POST es idempotente. No lo es: dos POST iguales crean dos recursos. El idempotente que no es seguro es PUT.
• Devolver 200 al crear un recurso. El código específico existe y es el 201, con Location apuntando al recurso creado.
• Intercambiar HttpOnly y SameSite. El primero deja fuera al código de la página; el segundo, a las peticiones de otros sitios.
• Pensar que el certificado lleva la clave privada. Lleva la pública; la privada no sale del servidor.
• Decir que TLS 1.3 elimina los certificados. Los mantiene: lo que hace es cerrar el acuerdo en una vuelta y retirar los algoritmos débiles.
• Citar la RFC 8446 como especificación de TLS 1.3. Desde julio de 2026 es la RFC 9846.
• Dar por buena la edición de 2021 del OWASP Top 10. La lista en vigor es la de 2025, con la cadena de suministro y la gestión de condiciones excepcionales como categorías nuevas.
• Cerrar el puerto 80 creyendo que es más seguro. El CCN recomienda dejarlo y redirigir a HTTPS.
• Atribuir UDDI a REST. Es del mundo SOAP; REST no publica en registros UDDI.
• Creer que CORS protege la interfaz. Solo relaja la política del mismo origen en el navegador: no sustituye a la autorización ni a un cortafuegos.
• Colocar la cita previa entre los canales de asistencia del artículo 4 del RD 203/2021. No está: son oficinas de registro, teléfono, correo electrónico y sedes.
• Suponer que el JWT va cifrado. Va firmado: cualquiera que lo tenga puede leer su contenido.

26. Lo que ya ha preguntado el tribunal

Respuestas verificadas contra el corpus de los nueve exámenes, para el repaso de la víspera:

• Método idempotente pero no seguro: PUT.
• Código al crear un recurso: 201 Created. Sin autorización: 403. Al superar el límite de peticiones: 429. Servicio no disponible: 503. Familia de error del cliente: 4xx. Familia 3xx: redirecciones, el cliente debe tomar una acción adicional.
• Atributo que impide que los scripts del cliente lean la cookie: HttpOnly. Atributo que la envía solo si se originó en el mismo sitio: SameSite.
• Cabecera contra el rastreo MIME: X-Content-Type-Options: nosniff. Autenticación con un valor de tres bloques tras «Bearer»: JWT. Para restringir el origen de las peticiones cruzadas: CORS.
• Recomendación de OWASP contra el XSS: validar y escapar los datos antes de mostrarlos en el navegador.
• Ventaja de TLS 1.3: acuerdo en un solo viaje de ida y vuelta. Tras un ClientHello aceptado, el servidor manda el ServerHello. Última versión estable: TLS 1.3. Según el CCN: mínima la 1.2, recomendada la 1.3.
• Del certificado: el navegador necesita la clave pública; lo que no contiene es la clave privada.
• Recomendación del CCN sobre el puerto 80: dejarlo y redirigir a HTTPS.
• Módulo que filtra y monitoriza el tráfico HTTP hacia los servidores web: WAF. Proxy-caché con HTTP, HTTP/2 y HTTPS: SQUID. Validar la configuración de Nagios: nagios -v con su fichero. Sonda SAT INET: túnel cifrado iniciado desde la sonda hacia el sistema central.
• IPP: colección de estándares abiertos que define un protocolo de impresión en red de alto nivel. RSVP: RFC 2205, reserva de recursos para servicios integrados. ITU: organismo de telecomunicaciones de la ONU. IETF: creador de los estándares de Internet.
• De REST: no guarda el estado del cliente entre peticiones, y UDDI no es una de sus características.
• LO 3/2018: los derechos y libertades constitucionales son plenamente aplicables en Internet, con la colaboración de los prestadores; y existe el derecho a la desconexión digital. RD 203/2021, art. 4: la cita previa no es un canal de asistencia.

27. Autoevaluación

Doce preguntas de control. Más de tres fallos significa que el tema no está listo:

1. ¿Qué método es idempotente pero no seguro, y por qué POST no lo es?
2. Un servicio REST acaba de crear un alumno: ¿qué código devuelve y qué cabecera acompaña?
3. Diferencia exacta entre 401 y 403, y cuándo conviene responder 404 en lugar de 403.
4. ¿Qué atributo de cookie deja fuera a JavaScript y cuál a las peticiones de otro sitio?
5. ¿Qué mensaje manda el servidor tras aceptar los parámetros de un ClientHello?
6. ¿Cuántas vueltas necesita el acuerdo en TLS 1.3 y qué versión es la mínima aceptable según el CCN?
7. ¿Qué RFC especifica hoy TLS 1.3 y cuál dejó obsoleta?
8. ¿Qué parte del certificado usa el navegador y qué parte no está nunca en él?
9. ¿Qué diferencia a HTTP/3 de HTTP/2 en cuanto al bloqueo de cabecera de línea?
10. ¿Qué cabecera evita el rastreo de tipo MIME y qué mecanismo autoriza peticiones de origen cruzado?
11. ¿Cuál es la edición vigente del OWASP Top 10 y cuáles son sus dos categorías nuevas?
12. Según el artículo 4 del RD 203/2021, ¿cuáles son los canales de asistencia y cuál no lo es?