Tema 6 Servicios Http

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/xmng,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 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

PHP/4.2.2

<-- 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 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

PHP/4.2.2

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. Algoritmo de hash • Respuesta del servidor, con envío de su 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