FUOC P03/75070/02123 FUOC XP04/90789/00892

58

Mecanismos de proteccin

4. Proteccin del nivel de transporte: SSL/TLS/WTLS

Tal y como hemos visto en el apartado anterior, el uso de un protocolo seguro a nivel de red puede requerir la adaptacin de la infraestructura de comunicaciones, por ejemplo cambiar los encaminadores IP por otros que entiendan IPsec.

Un mtodo alternativo que no necesita modicaciones en los equipos de interconexin es introducir la seguridad en los protocolos de transporte. La solucin ms usada actualmente es el uso del protocolo SSL o de otros basados en SSL.

Este grupo de protocolos comprende:

El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los aos 90. La primera versin de este protocolo ampliamente difundida y implementada fue la 2.0. Poco despus Netscape public la versin 3.0, con muchos cambios respecto a la anterior, que hoy ya casi no e utiliza. La especicacin Transport Layer Security (TLS), elaborada por la IETF (Internet Engineering Task Force). La versin 1.0 del protocolo TLS est publicada en el documento RFC 2246. Es prcticamente equivalente a SSL 3.0 con algunas pequeas diferencias, por lo que en ciertos contextos se considera el TLS 1.0 como si fuera el protocolo SSL 3.1. El protocolo Wireless Transport Layer Security (WTLS), perteneciente a la familia de protocolos WAP (Wireless Application Protocol) para el acceso a la red des de dispositivos mviles. La mayora de los protocolos WAP son adaptaciones de los ya existentes a las caractersticas de las comunicaciones inalmbricas, y en particular el WTLS est basado en el TLS 1.0. Las diferencias se centran principalmente en aspectos relativos a el uso eciente del ancho de banda y de la capacidad de clculo de los dispositivos, que puede ser limitada.

En este apartado hablaremos de les caractersticas comunes a SSL 3.0 y TLS 1.0, con algn detalle particular a las diferencias entre ellos. La mayora de referencias a los protocolos SSL/TLS se deben entender aplicables tambin a WTLS.

FUOC P03/75070/02123 FUOC XP04/90789/00892

59

Mecanismos de proteccin

4.1. Caractersticas del protocolo SSL/TLS El objetivo inicial del diseo del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta proteccin deba permitir al cliente asegurarse que se haba conectado al servidor autntico, y enviarle datos condenciales, como por ejemplo un nmero de tarjeta de crdito, con la conanza que nadie ms que el servidor sera capaz de ver estos datos. Las funciones de seguridad, pero, no se implementaron directamente en el protocolo de aplicacin HTTP, si no que se opt por introducirlas a nivel de transporte. De este modo podra haber muchas ms aplicaciones que hicieran uso de esta funcionalidad. Con este n se desarroll una interfaz de acceso a los servicios del nivel de transporte basada en la interfaz estndar de los sockets. En esta nueva interfaz, funciones como connect, accept, send o recv fueron sustituidas por otras equivalentes pero que utilizaban un protocolo de transporte seguro: SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseo se realiz de tal modo que cualquier aplicacin que utilizara TCP a travs de las llamadas de los sockets poda hacer uso del protocolo SSL solamente cambiando estas llamadas. De aqu proviene el nombre del protocolo.

Datagramas en WTLS
Una caracterstica distintiva del WTLS es que no solamente permite proteger conexiones TCP, como hacen SSL y TLS, si no que tambin dene un mecanismo de proteccin para las comunicaciones en modo datagrama, usadas en diversas aplicaciones mviles.

Los servicios de seguridad que proporcionan los protocolos SSL/TLS son: Condencialidad. El ujo normal de informacin en una conexin SSL/TLS

FUOC P03/75070/02123 FUOC XP04/90789/00892

60

Mecanismos de proteccin

consiste en intercambiar paquetes con datos cifrados mediante claves simtricas (por motivos de eciencia y rapidez). Al inicio de cada sesin, cliente y servidor se ponen de acuerdo en que claves utilizarn para cifrar los datos. Siempre se utilizan dos claves distintas: una para los paquetes enviados del cliente al servidor, y la otra para los paquetes enviados en sentido contrario. Para evitar que un intruso que est escuchando el dilogo inicial pueda saber cuales son las claves acordadas, se sigue un mecanismo seguro de intercambio de claves, basado en criptografa de clave pblica. El algoritmo concreto para este intercambio tambin se negocia durante el establecimiento de la conexin. Autenticacin de entidad. Con un protocolo de reto-respuesta basado en rmas digitales el cliente pude conrmar la identidad del servidor al cual se ha conectado. Para validar las rmas el cliente necesita conocer la clave pblica del servidor, y esto normalmente se realiza a travs de certicados digitales. SSL/TLS tambin prev la autenticacin del cliente frente al servidor. Esta posibilidad, pero, no se usa tan a menudo porque muchas veces, en lugar de autenticar automticamente el cliente a nivel de transporte, las mismas aplicaciones utilizan su propio mtodo de autenticacin.
Autenticacin de cliente

Autenticacin de mensaje. Cada paquete enviado en una conexin SSL/TLS, a ms de ir cifrado, puede incorporar un cdigo MAC para que el destinatario compruebe que nadie ha modicado el paquete. Las claves secretas par el clculo de los cdigos MAC (una para cada sentido) tambin se acuerdan de forma segura en el dilogo inicial. A ms, los protocolos SSL/TLS estn diseados con estos criterios adicionales: Eciencia. Dos de las caractersticas de SSL/TLS, la denicin de sesiones y la compresin de los datos, permiten mejorar la eciencia de la comunicacin.

Un ejemplo de autenticacin de cliente a nivel de aplicacin son las contraseas que pueden introducir los usuarios en formularios HTML. Si la aplicacin utiliza este mtodo, al servidor ya no le hace falta autenticar al cliente a nivel de transporte.

Si el cliente pide dos o ms conexiones simultneas o muy seguidas, en lugar de repetir la autenticacin y el intercambio de claves (operaciones computacionalmente costosas porque intervienen algoritmos de clave pblica), hay la opcin de reutilizar los parmetros previamente acordados. Si se hace uso de esta opcin, se considera que la nueva conexin pertenece a la misma sesin que la anterior. En el establecimiento de cada conexin se especica un identicador de sesin, que permite saber si la conexin empieza una sesin nueva o es continuacin de otra.

Conexiones consecutivas o simultneas

Una situacin tpica en que se utiliza SSL/TLS es la de un navegador web que accede a una pgina HTML que contiene imgenes: con HTTP no persistente (el nico modo denido en HTTP 1.0), esto requiere una primera conexin para la pgina y a continuacin tantas conexiones como imgenes haya. Si las conexiones pertenecen a la misma sesin SSL/TLS, slo hace falta realizar la negociacin una vez.

SSL/TLS prev la negociacin de algoritmos de compresin para los datos intercambiados, para compensar el trco adicional que introduce la seguridad. Pero ni SSL 3.0 ni TLS 1.0 especican ningn algoritmo concreto de compresin.

Extensibilidad. Al inicio de cada sesin, cliente y servidor negocian los algoritmos que utilizarn para el intercambio de claves, la autenticacin y el cifrado (a ms del algoritmo de compresin). Las especicaciones de los protocolos incluyen unas combinaciones predenidas de algoritmos criptogrcos,

FUOC P03/75070/02123 FUOC XP04/90789/00892

61

Mecanismos de proteccin

pero dejan abierta la posibilidad de aadir nuevos algoritmos si se descubren otros que sean ms ecientes o ms seguros.

4.2. El transporte seguro SSL/TLS La capa de transporte seguro que proporciona SSL/TLS se puede considerar dividida en dos subcapas.
La subcapa superior se encarga bsicamente de negociar los parmetros de seguridad y de transferir los datos de la aplicacin. Tanto los datos de negociacin como los de aplicacin se intercambian en mensajes. En la subcapa inferior, estos mensajes son estructurados en registros a los cuales se les aplica, segn corresponda, la compresin, la autenticacin y el cifrado.

El protocolo de registros SSL/TLS es el que permite que los datos protegidos sean convenientemente codicados por el emisor y interpretados por el receptor. Los parmetros necesarios para la proteccin, como pueden ser los algoritmos y las claves, se establecen de forma segura al inicio de la conexin mediante el protocolo de negociacin SSL/TLS. A continuacin veremos las caractersticas de cada uno de estos dos protocolos.

FUOC P03/75070/02123 FUOC XP04/90789/00892

62

Mecanismos de proteccin

4.2.1. El protocolo de registros SSL/TLS La informacin que se intercambian cliente y servidor en una conexin SSL/ TLS se empaqueta en registros, que tienen este formato:

El signicado de cada campo es el siguiente:

El primer campo indica cual es el tipo de contenido de los datos, que puede ser:

un mensaje del protocolo de negociacin, una noticacin de cambio de cifrado, un mensaje de error, o datos de aplicacin.
El segundo campo son dos bytes que indican la versin del protocolo: si son iguales a 3 y 0 el protocolo es SSL 3.0, y si son iguales a 3 y 1 el protocolo es TLS 1.0. El tercer campo indica la longitud del resto del registro. Por tanto, es igual a la suma de Ld y LMAC y, si los datos estn cifrados con un algoritmo en bloque, L p + 1. El cuarto campo son los datos, comprimidos si se ha acordado algn algoritmo de compresin. El quinto campo es el cdigo de autenticacin (MAC). En el clculo de este MAC intervienen la clave MAC, un nmero de secuencia implcito de 64 bits (que se incrementa en cada registro pero no se incluye en ningn campo) y, naturalmente, el contenido del registro.

Datos de un registro SSL/TLS

Normalmente los datos de un registro corresponden a un mensaje de la subcapa superior, pero tambin es posible juntar en un mismo registro dos o ms mensajes, siempre que todos pertenecen al tipo indicado por el primer campo. Tambin puede pasar que un mensaje se fragmente en diversos registros, si su longitud es superior a un cierto mximo (16384 bytes antes de comprimir).

La longitud de este campo depende del algoritmo de MAC que se haya acordado utilizar. Puede ser igual a 0 si se utiliza el algoritmo nulo, que es el que se utiliza al inicio de la negociacin mientras no se ha acordado ningn otro.

FUOC P03/75070/02123 FUOC XP04/90789/00892

63

Mecanismos de proteccin

Si se ha acordado utilizar un algoritmo en bloque para cifrar los datos, es preciso aadir bytes adicionales (padding) a cada registro para tener un nmero total que sea mltiple de la longitud del bloque. La tcnica que se usa para saber cuantos bytes adicionales hay es poner al menos uno, y el valor del ltimo byte siempre indica cuantos otros bytes de padding hay antes (este valor puede ser 0 si slo faltaba un byte para tener un bloque entero).

Padding en SSL y TLS

Otra diferencia entre SSL y TLS est en los bytes de padding. En SSL debe haber el mnimo necesario, y su valor (excepto el ltimo byte) es irrelevante. En TLS todos los bytes de padding deben tener el mismo valor que el ltimo.

El protocolo de registros SSL/TLS se encarga de formar cada registro con sus campos correspondientes, calcular el MAC, y cifrar los datos, el MAC y el padding con los algoritmos y las claves que pertocan. En la fase de negociacin, mientras no se hayan acordado los algoritmos, los registros no se cifran ni se autentican, es decir, se aplican algoritmos nulos. Como veremos despus, pero, todo el proceso de negociacin queda autenticado a posteriori.

4.2.2. El protocolo de negociacin SSL/TLS

El protocolo de negociacin SSL/TLS, tambin llamado protocolo de encajada de manos (Handshake Protocol), tiene por nalidad autenticar el cliente y/o el servidor, y acordar los algoritmos y claves que se utilizaran de forma segura, es decir, garantizando la condencialidad y la integridad de la negociacin.

Como todos los mensajes SSL/TLS, los mensajes del protocolo de negociacin se incluyen dentro del campo de datos de los registros SSL/TLS para ser transmitidos al destinatario. La estructura de un mensaje de negociacin es la siguiente:

El contenido del mensaje tendr unos determinados campos dependiendo del tipo de mensaje de negociacin del que se trate. En total hay 10 tipos distintos,

FUOC P03/75070/02123 FUOC XP04/90789/00892

64

Mecanismos de proteccin

que veremos a continuacin en el orden en que se tienen que enviar. 1) Peticin de saludo (Hello Request) Cuando se establece una conexin, el servidor normalmente espera que el cliente inicie la negociacin. Alternativamente, puede optar por enviar un mensaje Hello Request para indicar al cliente que est preparado para empezar. Si durante la sesin el servidor quiere iniciar una renegociacin, tambin lo puede indicar al cliente enviando-le un mensaje de este tipo. 2) Saludo de cliente (Client Hello) El cliente enva un mensaje Client Hello al inicio de la conexin o como respuesta a un Hello Request. Este mensaje contiene la siguiente informacin:
La versin del protocolo que el cliente quiere utilizar. Una cadena de 32 bytes aleatorios. Opcionalmente, el identicador de una sesin anterior, si el cliente desea volver a utilizar los parmetros que se han acordado. La lista de las combinaciones de algoritmos criptogrcos que el cliente ofrece utilizar, por orden de preferencia. Cada combinacin incluye el algoritmo de cifrado, el algoritmo de MAC y el mtodo de intercambio de claves.
Algoritmos criptogrcos previstos en SSL/TLS SSL/TLS contempla los algoritmos criptogrcos siguientes: Cifrado: RC4, DES, Triple DES, RC2, IDEA y FORTEZZA (este ltimo slo en SSL 3.0). MAC: MD5 y SHA-1. Intercambio de claves: RSA, Dife-Hellman y FORTEZZA KEA (este ltimo slo en SSL 3.0). Si solamente interesa autenticar la conexin, sin condencialidad, tambin se puede usar el algoritmo de cifrado nulo. Bytes aleatorios
De los 32 bytes aleatorios que se envan en los mensajes de saludo, los 4 primeros deben ser una marca de tiempo, con precisin de segundos.

La lista de los algoritmos de compresin ofrecidos, por orden de preferencia (como mnimo debe haber uno, aunque sea el algoritmo nulo).

3) Saludo de servidor (Server Hello) Como respuesta, el servidor enva un mensaje Server Hello, que contiene esta informacin:
La versin del protocolo que se usar en la conexin. La versin ser igual a la que envi el cliente, o inferior si esta no es soportada por el servidor. Otra cadena de 32 bytes aleatorios.

Algoritmos de compresin
El nico algoritmo de compresin previsto en SSL/TLS es el algoritmo nulo, es decir, sin compresin.

FUOC P03/75070/02123 FUOC XP04/90789/00892

65

Mecanismos de proteccin

El identicador de la sesin actual. Si el cliente envi uno y el servidor quiere reprender la sesin correspondiente, debe responder con el mismo identicador. Si el servidor no quiere reemprender la sesin (o no puede porque ya no guarda la informacin necesaria), el identicador enviado ser diferente. Opcionalmente, el servidor puede no enviar ningn identicador para indicar que la sesin actual nunca no podr ser reemprendida. La combinacin de algoritmos criptogrcos escogida por el servidor de entre la lista de las enviadas por el cliente. Si se reemprende una sesin anterior, esta combinacin debe ser la misma que se utiliz entonces. El algoritmo de compresin escogido por el servidor, o el que se utiliz en la sesin que se reemprende.

Si se ha decidido continuar una sesin anterior, cliente y servidor ya pueden empezar a utilizar los algoritmos y claves previamente acordados y se saltan los mensajes que vienen a continuacin pasando directamente a los de nalizacin de la negociacin (mensajes Finished). 4) Certicado de servidor (Certicate) o intercambio de claves de servidor (Server Key Exchange) Si el servidor puede autenticarse frente al cliente, que es el caso ms habitual, enva el mensaje Certicate. Este mensaje normalmente contendr el certicado X.509 del servidor, o una cadena de certicados. Si el servidor no tiene certicado, o se ha acordado un mtodo de intercambio de claves que no precisa de l, debe mandar un mensaje Server Key Exchange, que contiene los parmetros necesarios para el mtodo a seguir. 5) Peticin de certicado (Certicate Request) En caso que se deba realizar tambin la autenticacin del cliente, el servidor le enva un mensaje Certicate Request. Este mensaje contiene una lista de los posibles tipos de certicado que el servidor puede admitir, por orden de preferencia, y una lista de los DN de las autoridades de certicacin que el servidor reconoce. 6) Fi de saludo de servidor (Server Hello Done) Para terminar esta primera fase del dilogo, el servidor enva un mensaje Server Hello Done. 7) Certicado de cliente (Certicate) Una vez el servidor ha mandado sus mensajes iniciales, el cliente ya sabe como continuar el protocolo de negociacin. En primer lugar, si el servidor le ha pedido un certicado y el cliente tiene alguno de las caractersticas solicitadas, lo enva en un mensaje Certicate. 8) Intercambio de claves de cliente (Client Key Exchange) El cliente enva un mensaje Client Key Exchange, el contenido del cual
Tipo de certicados
En SSL/TLS estn contemplados los certicados de clave pblica RSA, DSA o FORTEZZA KEA (este ltimo tipo solamente en SSL 3.0).

Cliente sin certicado

Si el cliente recibe una peticin de certicado pero no tiene ninguno apropiado, en SSL 3.0 debe enviar un mensaje de aviso, pero en TLS 1.0 debe enviar un mensaje Certicate vaco. En cualquier caso, el servidor puede responder con un error fatal, o bien continuar sin autenticar el cliente.

FUOC P03/75070/02123 FUOC XP04/90789/00892

66

Mecanismos de proteccin

depende del mtodo de intercambio de claves acordado. En caso de seguir el mtodo RSA, en este mensaje hay una cadena de 48 bytes que se usar como secreto pre-maestro, cifrada con la clave pblica del servidor. Entonces, cliente y servidor calculan el secreto maestro, que es otra cadena de 48 bytes. Para realizar esta clculo, se aplican funciones hash al secreto pre-maestro y a las cadenas aleatorias que se enviaron en los mensajes de saludo. A partir del secreto maestro y las cadenas aleatorias, se obtienen:
Las dos claves para el cifrado simtrico de los datos (una para cada sentido: de cliente a servidor y de servidor a cliente). Las dos claves MAC (tambin una para cada sentido). Los dos vectores de inicializacin para el cifrado, si se utiliza un algoritmo en bloque.
Ataques de versin del protocolo
Un posible ataque contra la negociacin es modicar los mensajes para que las dos partes acuerden utilizar el protocolo SSL 2.0, que es ms vulnerable. Para evitar este ataque, a los dos primeros bytes del secreto pre-maestro debe haber el nmero de versin que se envi en el mensaje Client Hello.

9) Vericacin de certicado (Certicate Verify) Si el cliente ha mandado un certicado en respuesta a un mensaje Certicate Request, ya puede autenticarse demostrando que posee la clave privada correspondiente mediante un mensaje Certicate Verify. Este mensaje contiene una rma, generada con la clave privada del cliente, de una cadena de bytes obtenida a partir de la concatenacin de todos los mensajes de negociacin intercambiados hasta el momento, desde el Client Hello hasta el Client Key Exchange. 10)Finalizacin (Finished) A partir de este punto ya se pueden utilizar los algoritmos criptogrcos negociados. Cada parte manda a la otra una noticacin de cambio de cifrado seguida de un mensaje Finished. La noticacin de cambio de cifrado sirve para indicar que el siguiente mensaje ser el primer enviado con los nuevos algoritmos y claves. El mensaje Finished sigue inmediatamente la noticacin de cambio de cifrado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a la concatenacin de todos los mensajes de negociacin intercambiados, des de el Client Hello hasta el anterior a este (incluyendo el mensaje Finished de la otra parte, si ya lo ha enviado). Normalmente ser el cliente el primer en enviar el mensaje Finished, pero en el caso de reemprender una sesin anterior, ser el servidor quien lo enviar primero, justo despus del Server Hello. El contenido del mensaje Finished sirve para vericar que la negociacin se ha llevado a cabo correctamente. Este mensaje tambin permite autenticar el servidor frente al cliente, ya que el primer necesita su clave privada para descifrar el mensaje Client Key Exchange y obtener las claves que se usarn en la comunicacin.
Vericacin de autenticidad en SSL y TLS
Una de las principales diferencias entre SSL 3.0 y TLS 1.0 est en la tcnica usada para obtener los cdigos de vericacin de los mensajes Finished, y tambin para calcular el secreto maestro y para obtener las claves a partir de este secreto (en SSL se utilizan funciones hash directamente, y en TLS se utilizan cdigos HMAC).

FUOC P03/75070/02123 FUOC XP04/90789/00892

67

Mecanismos de proteccin

Una vez enviado el mensaje Finished, se da por acabada la negociacin, y cliente y servidor pueden empezar a enviar los datos de aplicacin utilizando los algoritmos y claves acordados. Los siguientes diagramas resumen los mensajes intercambiados durante la fase de negociacin SSL/TLS:

FUOC P03/75070/02123 FUOC XP04/90789/00892

68

Mecanismos de proteccin

A ms de los mensajes de negociacin, noticaciones de cambio de cifrado y datos de aplicacin, tambin se pueden enviar mensajes de error. Estos mensajes contienen un cdigo de nivel de gravedad, que puede ser mensaje de aviso o error fatal, y un cdigo de descripcin del error. Un error fatal provoca el n de la conexin y la invalidacin del identicador de sesin correspondiente, es decir, la sesin no podr ser reemprendida. Son ejemplos de errores fatales: MAC incorrecto, tipo de mensaje inesperado, error de negociacin, etc. (TLS 1.0 prev ms cdigos de error que SSL 3.0). Tambin se puede enviar un mensaje de aviso para indicar el n normal de la conexin. Para evitar ataques de truncamiento, si una conexin acaba sin haber enviado este aviso se invalidar su identicador de sesin.

4.3. Ataques contra el protocolo SSL/TLS Los protocolos SSL/TLS estn diseados para resistir los siguientes ataques: Lectura de los paquetes enviados por el cliente y servidor. Cuando los datos se envan cifrados, un atacante que pueda leer los paquetes, por ejemplo utilizando tcnicas de snifng, se enfrenta al problema de romper el cifrado si quiere interpretar su contenido. Las claves que se utilizan para el cifrado se intercambian con mtodos de clave pblica, que el atacante tendra que romper si quiere saber cuales son los valores acordados.

FUOC P03/75070/02123 FUOC XP04/90789/00892

69

Mecanismos de proteccin

Es preciso advertir, pero, que dependiendo de la aplicacin que lo utilice, el protocolo SSL/TLS puede ser objeto de ataques con texto en claro conocido. Por ejemplo, cuando se utiliza juntamente con HTTP para acceder a servidores web con contenidos conocidos. Si la comunicacin es totalmente annima, es decir sin autenticacin de servidor ni cliente, s que existe la posibilidad de capturar las claves secretas con un ataque conocido como hombre a medio camino (en ingls, man-in-themiddle attack). En este ataque el espa genera sus propias claves pblicas y privadas, y cuando una parte enva a la otra informacin sobre su clave pblica, tanto en un sentido como en el otro, el atacante la intercepta y la sustituye por la equivalente con la clave pblica fraudulenta. Dado que el intercambio es annimo, el receptor no tiene manera de saber si la clave pblica que recibe es la del emisor autntico o no. En cambio, si se realiza la autenticacin de servidor y/o cliente, es necesario enviar un certicado donde tiene que haber la clave pblica del emisor rmada por una autoridad de certicacin que el receptor reconozca, y por tanto no puede ser sustituida por otra. Suplantacin de servidor o cliente. Cuando se realiza la autenticacin de servidor o cliente, el certicado digital debidamente rmado por la CA sirve para vericar la identidad de su propietario. Un atacante que quiera hacerse pasar por el servidor (o cliente) autntico debera obtener su clave privada, o bien la de la autoridad de certicacin que ha emitido el certicado para poder generar otro con una clave pblica diferente y que parezca autntico. Alteracin de los paquetes. Un atacante puede modicar los paquetes para que lleguen al destinatario con un contenido distinto del original (si estn cifrados no podr controlar cual ser el contenido nal descifrado, solamente sabr que ser distinto al original). Si pasa esto, el receptor detectar que el paquete ha sido alterado porque el cdigo de autenticacin (MAC) casi con total seguridad ser incorrecto. Si la alteracin se realiza en los mensajes de negociacin cuando aun no se aplica ningn cdigo MAC, con la nalidad por ejemplo de forzar la adopcin de algoritmos criptogrcos ms dbiles y vulnerables, esta manipulacin ser detectada en la vericacin de los mensajes Finished. Repeticin, eliminacin o reordenacin de paquetes. Si el atacante vuelve a enviar un paquete correcto que ya haba sido enviado antes, o suprime algn paquete haciendo que no llegue a su destino, o los cambia de orden, el receptor lo detectar porque los cdigos MAC no coincidirn con el valor esperado. Esto es as porque en el clculo del MAC se utiliza un nmero de secuencia que se va incrementando en cada paquete. Tampoco se pueden copiar los mensajes enviados en un sentido (de cliente a servidor o de servidor a cliente) al sentido contrario, porque en los dos ujos de la comunicacin se utilizan claves de cifrado y de MAC diferentes.

FUOC P03/75070/02123 FUOC XP04/90789/00892

70

Mecanismos de proteccin

Como consideracin nal, cabe destacar que la fortaleza de los protocolos seguros recae no solamente en su diseo si no en el de las implementaciones. Si una implementacin solamente soporta algoritmos criptogrcos dbiles (con pocos bits de clave), o genera nmeros pseudoaleatrios fcilmente predecibles, o guarda los valores secretos en almacenamiento (memoria o disco) accesible por atacantes, etc., no estar garantizando la seguridad del protocolo.

4.4. Aplicaciones que utilizan SSL/TLS Como hemos visto al inicio de este apartado, los protocolos SSL/TLS fueron diseados para permitir la proteccin de cualquier aplicacin basada en un protocolo de transporte como TCP. Algunas aplicaciones que utilizan esta caracterstica son:
HTTPS (HTTP sobre SSL/TLS): el protocolo ms utilizado actualmente para la navegacin web segura. NNTPS (NNTP sobre SSL): para el acceso seguro al servicio de News.

Estas aplicaciones con SSL/TLS funcionan exactamente igual que las originales. Las nicas diferencias son el uso de la capa de transporte seguro que proporciona SSL/TLS y la asignacin de nmeros de puerto TCP propios: 443 para HTTPS y 563 para NNTPS. En muchos otros casos, pero, es preferible aprovechar los mecanismos de extensin previstos en el propio protocolo de aplicacin, si hay, para negociar el uso de SSL/TLS, a n de evitar la utilizacin innecesaria de nuevos puertos TCP. As lo hacen aplicaciones como:
TELNET, usando la opcin de autenticacin (RFC 1416). FTP, usando las extensiones de seguridad (RFC 2228). SMTP, usando sus extensiones para SSL/TLS (RFC 2487). POP3 y IMAP, tambin usando comandos especcos para SSL/TLS (RFC 2595).

Tambin hay denido un mecanismo para negociar el uso de SSL/TLS en HTTP (RFC 2817), como alternativa a HTTPS.