FUOC P03/75070/02123 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 comuni-
caciones, 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 es-
t 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 comunica-
ciones inalmbricas, y en particular el WTLS est basado en el TLS 1.0.
Las diferencias se centran principalmente en aspectos relativos a el uso e-
ciente 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 ref-
erencias a los protocolos SSL/TLS se deben entender aplicables tambin a
WTLS.
FUOC XP04/90789/00892
FUOC P03/75070/02123 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
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.
transporte basada en la interfaz estndar de los sockets. En esta nueva inter-
faz, 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 cam-
biando estas llamadas. De aqu proviene el nombre del protocolo.
Los servicios de seguridad que proporcionan los protocolos SSL/TLS son:
Condencialidad. El ujo normal de informacin en una conexin SSL/TLS
FUOC XP04/90789/00892
FUOC P03/75070/02123 60 Mecanismos de proteccin
consiste en intercambiar paquetes con datos cifrados mediante claves simtri-
cas (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 r-
mas 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 aplica-
ciones utilizan su propio mtodo de autenticacin.
Autenticacin de cliente
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.
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.
Ams, 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.
Si el cliente pide dos o ms conexiones simultneas o muy seguidas, en lu-
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.
gar de repetir la autenticacin y el intercambio de claves (operaciones com-
putacionalmente 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.
SSL/TLS prev la negociacin de algoritmos de compresin para los datos
intercambiados, para compensar el trco adicional que introduce la se-
guridad. 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 algo-
ritmos que utilizarn para el intercambio de claves, la autenticacin y el cifra-
do (a ms del algoritmo de compresin). Las especicaciones de los proto-
colos incluyen unas combinaciones predenidas de algoritmos criptogrcos,
FUOC XP04/90789/00892
FUOC P03/75070/02123 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 protegi-
dos 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 XP04/90789/00892
FUOC P03/75070/02123 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:
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).
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 L
d
y L
MAC
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 algo-
ritmo 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.
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 XP04/90789/00892
FUOC P03/75070/02123 63 Mecanismos de proteccin
Si se ha acordado utilizar un algoritmo en bloque para cifrar los datos,
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.
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).
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 autenti-
cado 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 aut-
enticar 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 trans-
mitidos al destinatario. La estructura de un mensaje de negociacin es la sigu-
iente:
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 XP04/90789/00892
FUOC P03/75070/02123 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 informa-
cin:
La versin del protocolo que el cliente quiere utilizar.
Una cadena de 32 bytes aleatorios.
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.
Opcionalmente, el identicador de una sesin anterior, si el cliente de-
sea 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.
La lista de los algoritmos de compresin ofrecidos, por orden de pref-
erencia (como mnimo debe haber uno, aunque sea el algoritmo nulo).
Algoritmos de
compresin
El nico algoritmo de
compresin previsto en
SSL/TLS es el algoritmo
nulo, es decir, sin
compresin.
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.
FUOC XP04/90789/00892
FUOC P03/75070/02123 65 Mecanismos de proteccin
El identicador de la sesin actual. Si el cliente envi uno y el servi-
dor 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 iden-
ticador 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 habit-
ual, 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 inter-
cambio 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 servi-
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).
dor 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 certi-
cacin 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
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.
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
FUOC XP04/90789/00892
FUOC P03/75070/02123 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.
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.
Entonces, cliente y servidor calculan el secreto maestro, que es otra ca-
dena 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 men-
sajes 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 algo-
ritmo en bloque.
9) Vericacin de certicado (Certicate Verify)
Si el cliente ha mandado un certicado en respuesta a un mensaje Certi-
cate Request, ya puede autenticarse demostrando que posee la clave priva-
da correspondiente mediante un mensaje Certicate Verify. Este mensaje
contiene una rma, generada con la clave privada del cliente, de una cade-
na 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
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).
cifrado. Su contenido se obtiene aplicando funciones hash al secreto mae-
stro y a la concatenacin de todos los mensajes de negociacin intercambi-
ados, 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.
FUOC XP04/90789/00892
FUOC P03/75070/02123 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 utilizan-
do los algoritmos y claves acordados.
Los siguientes diagramas resumen los mensajes intercambiados durante la fase
de negociacin SSL/TLS:
FUOC XP04/90789/00892
FUOC P03/75070/02123 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 men-
sajes 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 cor-
respondiente, es decir, la sesin no podr ser reemprendida. Son ejemplos de
errores fatales: MAC incorrecto, tipo de mensaje inesperado, error de nego-
ciacin, 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 uti-
lizando 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 XP04/90789/00892
FUOC P03/75070/02123 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 servi-
dor 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-the-
middle 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 pbli-
ca, 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 servi-
dor 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 bi-
en 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 cifra-
dos no podr controlar cual ser el contenido nal descifrado, solamente sabr
que ser distinto al original). Si pasa esto, el receptor detectar que el paque-
te 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 XP04/90789/00892
FUOC P03/75070/02123 70 Mecanismos de proteccin
Como consideracin nal, cabe destacar que la fortaleza de los protocolos se-
guros 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 pre-
decibles, 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 origi-
nales. 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 ex-
tensin 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 (RFC2595).
Tambin hay denido un mecanismo para negociar el uso de SSL/TLS en
HTTP (RFC 2817), como alternativa a HTTPS.
FUOC XP04/90789/00892