TEMA 6 - SERVICIOS HTTP

1 Funcionamiento del protocolo HTTP

El protocolo HTTP es el usado en lo que popularmente se conoce como web. Se usa
tanto para que el navegador pida una página a un servidor, como para que éste envíe
la página solicitada al navegador. Está basado en el envío de comandos y respuestas
en texto ASCII, si bien cada tipo de contenido enviado (archivo en formato HTML,
imágenes en diversos formatos, documentos en formato PDF, etc.) se enviará tal cual
está almacenado en el servidor. Es decir, los archivos binarios se envían tal cual,
aunque los comandos y las respuestas del protocolo HTTP vayan siempre en texto.
En realidad, cuando un navegador conecta con un servidor web remoto no sólo le
solicita la página cuya URL el usuario ha tecleado (o la indicada en el enlace
seleccionado con el ratón), sino que le informa de detalles del navegador, de la página
que solicita, etc. Quizás viendo un ejemplo esto último quede más claro. A
continuación se muestra una petición HTTP típica:
GET / HTTP/1.1
Host: www.24x7linux.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b)
Gecko/20021016
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-
mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
Accept-Language: es-es, en-us;q=0.66, en;q=0.33
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-15, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
El proceso completo es el siguiente. El usuario teclea www.24x7linux en su navegador
(el prefijo http:// indica el protocolo que habrá de usar el navegador tras conectar con
el servidor, que es el protocolo predeterminado). El navegador realiza una consulta
DNS para averiguar la dirección IP asociada al nombre www.24x7linux.com, por
ejemplo 66.227.74.170. Y entonces intenta establecer una conexión TCP al puerto 80
(el predeterminado para los servidores web).
Cuando dicha conexión se ha establecido, el navegador envía la petición HTTP
solicitando la página indicada tecleada por el usuario. Puesto que no se indicó una
página en concreto, el navegador asume que se solicita la página principal, que se
representa como /. Como se ve en el listado anterior, además se envía información
adicional.
Por ejemplo, se informa del navegador en uso (User-Agent) y en qué idioma se
prefiere visualizar la página que se está solicitando (Accept-Language) (esto permite
que una web albergue los contenidos en varios idiomas, y se le envía al navegador la
versión en el idioma que tenga configurado en sus opciones).
Las cabeceras Accept-Encoding y Accept-Charset y Accept le indican al servidor qué
tipos de contenidos el navegador entiende y sabe representar. Por ejemplo, mientras
que el navegador usado entiende imágenes PNG (image/png), es muy probable que
un navegador en modo texto no, y por lo tanto enviará unas cabeceras acorde con sus
capacidades. De hecho, estas y otras cabeceras son personalizables, de manera que
podemos forzar que nuestro navegador se identifique como otro, para entrar en esos
sitios que nos impiden el acceso por la arbitraria razón de no usar un navegador en
concreto.
La pareja de cabeceras Keep-Alive y Connection, sólo está presente en la versión 1.1
del protocolo HTTP, y permite recibir muchos recursos (páginas HTML, imágenes,
Servicios HTTP 1
etc.) a través de la conexión TCP recién establecida. En la versión 1.0 del protocolo
HTTP era necesario establecer y terminar una conexión TCP por cada recurso, lo que
resultaba tremendamente ineficiente.
Hasta ahora, el servidor sólo sabe que tiene que enviar al navegador remoto la página
inicial del servidor web asociado a la IP a que se ha conectado. Pero no sería posible
tener hospedadas las páginas de varios clientes en el mismo servidor y usando la
misma dirección IP (virtual hosting). Para ello, la versión 1.1 del protocolo HTTP
añadió la obligatoriedad de la cabecera Host, que indica al servidor las páginas de qué
sitio queremos ver, aunque haya varias asociadas a un servidor web en la misma
dirección IP.
El servidor recibe todas estas (y posiblemente más cabeceras, por ejemplo, en el caso
de que haya algún proxy intermedio), las interpreta, y devolverá al navegador una
respuesta estándar HTTP (indicando si la petición tuvo éxito o no), y a continuación la
página solicitada. En el caso de la página principal implícita (/), el servidor la tendrá
configurada en un archivo, normalmente index.html, que enviará en caso de no
especificarse una página en concreto:
HTTP/1.1 200 OK
Date: Sun, 10 Nov 2002 22:50:55 GMT
Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2
mod_log_bytes/0.3
FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b
Content-Type: text/html
Age: 130
Connection: close

<-- archivo index.html que contiene la página principal del sitio -->
Se ha recortado la respuesta del servidor web a la parte interesante de la misma.
Como se ve, en primer lugar el servidor informa del éxito de la petición (200 OK) y de
la versión del protocolo que conoce (HTTP/1.1). También indica la fecha y hora en el
servidor (Date) y la versión y módulos del servidor web (Server).
Lo realmente interesante es la cabecera Content-Type, que le dice al navegador el tipo
de contenido que viene a continuación (text/html) seguido del contenido propiamente
dicho (el archivo index.html en el directorio base del servidor web). Si en lugar de pedir
una página en formato HTML se solicita un recurso binario, como por ejemplo un
archivo gráfico, la respuesta será de la forma siguiente:
HTTP/1.1 200 OK
Date: Sun, 10 Nov 2002 23:15:31 GMT
Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2
mod_log_bytes/0.3
FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b
Last-Modified: Fri, 01 Nov 2002 12:23:38 GMT
ETag: "23c32f-171cb-3dc2724a"
Accept-Ranges: bytes
Content-Length: 94667
Content-Type: image/png
Age: 131
Una respuesta como la primera, pero en este caso se indica que a continuación viene
el contenido de un archivo binario en formato PNG, el tamaño en octetos del archivo, y
la fecha de su última modificación. Esta fecha, y el valor de las etiquetas ETag son
usados por los cachés de protocolo HTTP para decidir si almacenar o no en su
memoria y disco el recurso al cual se refieren, por considerarlo más reciente que la
copia que ya tenían (en caso de tenerla). Cuando alguien vuelve a solicitar ese mismo
recurso y la caché ve la petición, devuelve al cliente la copia almacenada en su
memoria, lo cual acelera la carga del recurso y reduce la carga en los enlaces de la
red y en el servidor remoto.

Servicios HTTP 2
Evidentemente el protocolo HTTP es mucho más amplio pero sirve para saber qué
sucede desde que introducimos una URL en nuestro navegador, hasta que vemos el
resultado en pantalla. Saber estos detalles es especialmente útil a la hora de intentar
resolver problemas de navegación.

2 Protocolos seguros y claves

A continuación se expone el protocolo de encriptación SSL (Secured Sockets Layer),
utilizado en transacciones seguras vía Web (mediante autenticación) entre un cliente y
en servidor. Además, habilita la posibilidad de utilizar firmas digitales, algoritmos de
criptografía y algoritmos de digest o de resumen de mensajes (toman como entrada un
mensaje de longitud variable y producen un resumen de longitud fija).
El protocolo SSL es un sistema diseñado y propuesto por Netscape Communications
Corporation, y se encuentra en la pila OSI en el nivel de sesión.
Por tanto, los servicios proporcionados por SSL son autenticación, integridad y
confidencialidad. Evidentemente, tras la utilización de este protocolo la entidad
servidora puede catalogar al cliente de la comunicación como «fiable».
La clave de sesión es la que se utiliza para cifrar los datos que vienen y van al servidor
seguro. Se genera una distinta para cada transacción, por lo que un fallo de seguridad
de una transacción no implica el fallo de las siguientes.
El modo de actuación del protocolo es el siguiente:
• Solicitud del cliente: el cliente solicita una URL
con soporte SSL. A continuación, se acuerda la
conexión SSL (este paso se conoce como
handshake o apretón de manos). MD5 se suele
usar como algoritmo de hash.
• Establecimiento de la conexión SSL.
• Verificación del servidor desde el cliente y
acuerdo del algoritmo de criptografía.
• Respuesta del servidor, con envío de su Algoritmo de hash
identificador (que lleva incluido la clave pública,
algoritmos criptográficos, etcétera).

Servicios HTTP 3
La aprobación del cliente se realiza cuando éste verifica la validez del identificador
digital del servidor, desencriptándolo y utilizando su clave pública. También se suelen
autenticar fechas, URL, etc. Una vez verificada la identidad, el cliente genera una
clave aleatoria y la encripta utilizando la clave pública del servidor y el algoritmo
concertado. A continuación la envía al servidor.
En este momento ambos conocen sus respectivas claves, de forma que están listos
para intercambiar información de forma segura utilizando la clave secreta acordada y
los algoritmos específicos. Para reutilizar en otra sesión el handshake, cada servidor
asigna a cada sesión SSL un identificador de sesión único, guardado en caché, que
utilizará el cliente para futuras conexiones.
Hay que señalar que, a pesar de utilizar claves de 128 bits, se han conseguido
rupturas de la seguridad, lo que indica que información muy sensible (como
transacciones que impliquen grandes cantidades de dinero) no están absolutamente
seguras utilizando protocolo SSL.
Cuando se abandona una sesión SSL, normalmente la aplicación presenta un
mensaje, advirtiendo que la comunicación no es segura y confirma que el cliente
desea efectivamente finalizar la sesión.
El protocolo SSL es sin duda alguna el más utilizado hoy en día en Internet,
utilizándolo casi todos los servidores de compras. Aun así, mantiene los defectos
antes mencionados: utilizar únicamente clave pública y no exigir verificación al cliente.

2.1 Protocolo HTTPS

El protocolo HTTPS es la versión segura del protocolo HTTP. El sistema HTTPS utiliza
un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado
(cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el
cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP.
Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar
HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos
no seguros (HTTP), estando conectados a un entorno seguro (HTTPS).
Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo
de servicio que requiera el envío de datos personales o contraseñas.
El puerto estándar para este protocolo es el 443.
El navegador indicará que emplea este protocolo encabezando la línea URL con
“https” . Si la página es un sitio seguro además mostrará un candado en la barra de
estado.

2.2 La firma electrónica

La firma electrónica permite identificar a la persona que realiza una transacción, es
decir, proporciona el servicio de autenticación y la fiabilidad de que el autor es quien
dice ser.
Una aplicación directa de estas tecnologías será el futuro Documento Nacional de
Identidad, que podrá ser utilizado para realizar gestiones oficiales en ámbitos
telemáticos.

Servicios HTTP 4
2.2.1 Cifrado
La mejor forma de proteger la información intercambiada por la Web es utilizar la
criptografía. Las técnicas de cifrado impiden que los usuarios no autorizados puedan
acceder al contenido de un documento, y sólo el usuario destinatario puede leerlo, ya
que sólo él es, capaz de descifrarlo. Aunque, aparentemente el cifrado asimétrico es
más seguro que el simétrico, todavía presenta algunos problemas, como son:
• La clave privada debe mantenerse en secreto.
• La clave pública debe ser conocida por todas aquellos usuarios que quieran
enviar un mensaje cifrado, y para ello hay que hacerla pública, como su
nombre indica.
• Cualquier usuario puede manipular la clave pública de otro usuario, y por ese
motivo aparecen las entidades que certifican la autenticidad de la clave pública
de un usuario.
Estas técnicas de cifrado preservan la confidencialidad. Pero existen en la actualidad
técnicas que, además de garantizar la confidencialidad, también aseguran la integridad
y la autenticación. Estas técnicas se basan en la utilización de la firma digital.

NOTA:
Cifrado simétrico. En este tipo de cifrado el emisor y el receptor comparten la misma clave,
teniendo un algoritmo común para cifrar y descifrar el mensaje transmitido. La clave única hay que
compartirla y, por tanto, tiene que viajar por la red con el riesgo de que sea leída.
Cifrado asimétrico. En este tipo de cifrado el usuario utiliza dos claves, una privada que sólo él
conoce, y una pública que debe ser conocida por los usuarios que quieran enviarle un mensaje
cifrado. Cuando se envía un mensaje cifrado, se utiliza la clave pública del usuario destino para
cifrarlo. Sólo el usuario destino, que conoce la clave privada correspondiente, puede descifrar el
mensaje. Hay, por tanto, una clave (la privada) que no viaja por la red.

2.2.2 Firma digital y certificado digital

La confidencialidad del
mensaje queda garantizada
con el cifrado del mismo. En
este apartado se verá cómo la
autenticación y la integridad
quedan garantizadas con la
utilización de la firma digital. Es
decir, con la firma digital se
asegura que el usuario que
firma el mensaje es quien dice
ser y la integridad del
contenido del mensaje.
Después de escribir el
mensaje, el usuario remitente
lo «firma» mediante su clave
privada. Una vez firmado, si se realiza cualquier modificación sobre el mensaje la firma
ya no es válida. El destinatario del mensaje, que debe conocer la clave pública del
remitente, puede comprobar que el mensaje es auténtico y no ha sido manipulado.
Como se puede deducir, la técnica de la firma digital se compone de una clave privada
y una clave pública o certificado digital. Es pues, un sistema basado en la criptografía
asimétrica. La firma digital, por tanto, codifica el contenido del mensaje, de tal
manera que únicamente puede ser decodificado por la clave pública que se
corresponde. La mejor o peor calidad de las claves utilizadas determina su nivel de
seguridad, y depende de los algoritmos utilizados en la creación de dichas claves.

Servicios HTTP 5
El problema de las firmas digitales es el de siempre: el cuidado que tiene el usuario en
la protección de sus claves. De nada sirve utilizar algoritmos sofisticados y
mecanismos muy seguros si luego el usuario no es capaz de cuidar de sus claves.
Para obtener el certificado digital se
debe acudir a una autoridad
certificadora, que llevará a cabo la
identificación personal. A continuación
genera las claves, pública y privada, y
entrega al usuario la tarjeta o disquete
que contiene esta clave privada, así
como el software necesario para su
uso y que ha de instalar el usuario en
su máquina. A partir de este momento
ya se puede utilizar la firma digital
para «firmar» los documentos que
considere el usuario y a los que se le
adjunta, al ser enviados por correo
electrónico, el certificado digital
obtenido a través de la autoridad
certificadora, y que garantiza la
identidad del usuario remitente.
Esta tarjeta contiene la clave privada y lleva un chip con información relativa al titular
de dicha tarjeta, la clave pública, el mecanismo de utilización de las claves, la fecha de
emisión, el periodo de validez, el número de serie, la identificación de la autoridad
certificadora, etc. Son tarjetas personales con un código secreto que sólo conoce el
titular y, se puede decir, que son como un DNI digital.
Se puede diferenciar entre firma electrónica y firma digital. La firma electrónica utiliza
el sistema de criptografía simétrica generando una misma clave para el emisor y el
receptor. La firma digital utiliza el sistema de criptografía asimétrico generando dos
claves, pública y privada. A nivel internacional, la legislación favorece la utilización de
la firma digital por ser más segura.

2.2.3 Autoridades certificadoras

La misión de las Autoridades Certificadoras es garantizar que el usuario sea realmente
la persona que dice ser. De esta forma el destinatario de un mensaje sabe con
seguridad quién se lo ha enviado.

Servicios HTTP 6
Algunos ejemplos de entidades de certificación son los siguientes:
• Fábrica Nacional de Moneda y Timbre (www.cert.fnmt.es/certif/): la FNMT es la
autoridad pública de certificación española (Proyecto CERES). Sus certificados
son utilizados para la relación de los usuarios con la Administración pública.
Por ejemplo, la Agencia Tributaria (http://www.aeat.es/) utiliza el certificado
emitido por la FNMT, ya que la declaración de la renta se puede presentar vía
Internet gracias a este proyecto.
• FESTE (http://www.feste.es): el Patronato de FESTE (Fundación para el
Estudio de la Seguridad de las Telecomunicaciones) está formado por el
Consejo General del Notariado, el Consejo General de la Abogacía y la
Universidad de Zaragoza. Su objetivo es garantizar las comunicaciones de tipo
electrónico, y para ello emiten tres tipos de certificados: notariales, certificados
web y certificados para ser utilizados por instituciones privadas.
• IPSCA (http://www.ipsca.es): es una empresa española que comercializa la
emisión de certificados digitales, como son los certificados de Servidor Seguro
para el comercio electrónico. También emite certificados de prueba de tres
meses de duración para firmar correos.
• VERISIGN (http://www.verisign.es): división española (creada en 2003) de la
empresa estadounidense VeriSign, pionera y líder a nivel mundial que
proporciona servicios de seguridad en Internet a empresas, tanto grandes
como medianas, y a usuarios particulares, entre ellas la emisión de certificados
digitales.

Servicios HTTP 7