7/30/2019 26118-ssl

1/13

FUOC P03/75070/02123 58 Mecanismos de proteccin4. 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 modificaciones 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 ala anterior, que hoy ya casi no e utiliza.

La especificacin 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 WAPson 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 efi-

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

7/30/2019 26118-ssl

2/13

FUOC P03/75070/02123 59 Mecanismos de proteccin4.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 confidenciales, como por ejemplo un nmero de tarjeta de

crdito, con la confianza 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 fin se desarroll una interfaz de acceso a los servicios del nivel deDatagramas en WTLS

Una caractersticadistintiva del WTLS esque no solamente permiteproteger conexiones TCP,como hacen SSL y TLS, sino que tambin define unmecanismo de proteccinpara las comunicacionesen modo datagrama,usadas en diversasaplicaciones 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:

Confidencialidad. El flujo normal de informacin en una conexin SSL/TLS

FUOC XP04/90789/00892

7/30/2019 26118-ssl

3/13

FUOC P03/75070/02123 60 Mecanismos de proteccinconsiste en intercambiar paquetes con datos cifrados mediante claves simtri-

cas (por motivos de eficiencia 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 fir-

mas digitales el cliente pude confirmar la identidad del servidor al cual se ha

conectado. Para validar las firmas el cliente necesita conocer la clave pblica

del servidor, y esto normalmente se realiza a travs de certificados 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 deautenticacin de cliente anivel de aplicacin son lascontraseas que puedenintroducir los usuarios enformularios HTML. Si laaplicacin utiliza estemtodo, al servidor ya nole hace falta autenticar alcliente a nivel detransporte.

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

Eficiencia. Dos de las caractersticas de SSL/TLS, la definicin de sesiones y

la compresin de los datos, permiten mejorar la eficiencia de la comunicacin.

Si el cliente pide dos o ms conexiones simultneas o muy seguidas, en lu-Conexiones consecutivas

o simultneas

Una situacin tpica enque se utiliza SSL/TLS es

la de un navegador webque accede a una pginaHTML que contieneimgenes: con HTTP nopersistente (el nicomodo definido enHTTP 1.0), esto requiereuna primera conexinpara la pgina y acontinuacin tantasconexiones comoimgenes haya. Si lasconexiones pertenecen ala misma sesin SSL/TLS,slo hace falta realizar lanegociacin 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 ala misma sesin que la anterior. En el establecimiento de cada conexin

se especifica un identificador 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 trfico adicional que introduce la se-

guridad. Pero ni SSL 3.0 ni TLS 1.0 especifican 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 especificaciones de los proto-

colos incluyen unas combinaciones predefinidas de algoritmos criptogrficos,

FUOC XP04/90789/00892

7/30/2019 26118-ssl

4/13

FUOC P03/75070/02123 61 Mecanismos de proteccinpero dejan abierta la posibilidad de aadir nuevos algoritmos si se descubren

otros que sean ms eficientes 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 codificados 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

7/30/2019 26118-ssl

5/13

FUOC P03/75070/02123 62 Mecanismos de proteccin4.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 significado 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 deun registro correspondena un mensaje de lasubcapa superior, perotambin es posible juntaren un mismo registro doso ms mensajes, siempreque todos pertenecen altipo indicado por el primercampo. Tambin puedepasar que un mensaje sefragmente en diversosregistros, si su longitud essuperior a un ciertomximo (16384 bytes

antes de comprimir).

un mensaje del protocolo de negociacin,

una notificacin 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 enbloque, Lp+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

7/30/2019 26118-ssl

6/13

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 SSLy TLS est en los bytes depadding. En SSL debehaber el mnimo

necesario, y su valor(excepto el ltimo byte) esirrelevante. En TLS todoslos bytes de paddingdeben tener el mismovalor 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 depadding 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 finalidad aut-

enticar el cliente y/o el servidor, y acordar los algoritmos y claves quese utilizaran de forma segura, es decir, garantizando la confidencialidad

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

7/30/2019 26118-ssl

7/13

FUOC P03/75070/02123 64 Mecanismos de proteccinque 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 enviarun 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 aleatoriosque se envan en losmensajes de saludo, los4 primeros deben ser unamarca de tiempo, conprecisin de segundos.

Opcionalmente, el identificador 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 criptogrficos 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 criptogrficos previstos en SSL/TLS

SSL/TLS contempla los algoritmos criptogrficos 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, Diffie-Hellman y FORTEZZA KEA (este ltimo

slo en SSL 3.0).

Si solamente interesa autenticar la conexin, sin confidencialidad, 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 decompresin previsto enSSL/TLS es el algoritmonulo, es decir, sincompresin.

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

7/30/2019 26118-ssl

8/13

FUOC P03/75070/02123 65 Mecanismos de proteccin El identificador de la sesin actual. Si el cliente envi uno y el servi-

dor quiere reprender la sesin correspondiente, debe responder con el

mismo identificador. Si el servidor no quiere reemprender la sesin

(o no puede porque ya no guarda la informacin necesaria), el iden-

tificador enviado ser diferente. Opcionalmente, el servidor puede no

enviar ningn identificador para indicar que la sesin actual nunca no

podr ser reemprendida.

La combinacin de algoritmos criptogrficos 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 sesaltan los mensajes que vienen a continuacin pasando directamente a los

de finalizacin de la negociacin (mensajes Finished).

4) Certificado de servidor (Certificate) 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 Certificate. Este mensaje normalmente contendr el

certificado X.509 del servidor, o una cadena de certificados.

Si el servidor no tiene certificado, 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 certificado (Certificate Request)

En caso que se deba realizar tambin la autenticacin del cliente, el servi-Tipo de certificados

En SSL/TLS estncontemplados loscertificados de clavepblica RSA, DSA oFORTEZZA KEA (este

ltimo tipo solamente enSSL 3.0).

dor le enva un mensaje Certificate Request. Este mensaje contiene una

lista de los posibles tipos de certificado que el servidor puede admitir, por

orden de preferencia, y una lista de los DN de las autoridades de certifi-

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) Certificado de cliente (Certificate)

Una vez el servidor ha mandado sus mensajes iniciales, el cliente ya sabe

Cliente sin certificado

Si el cliente recibe unapeticin de certificadopero no tiene ningunoapropiado, en SSL 3.0debe enviar un mensajede aviso, pero en TLS 1.0debe enviar un mensajeCertificate vaco. Encualquier caso, el servidorpuede responder con unerror fatal, o biencontinuar sin autenticar elcliente.

como continuar el protocolo de negociacin. En primer lugar, si el servidor

le ha pedido un certificado y el cliente tiene alguno de las caractersticas

solicitadas, lo enva en un mensaje Certificate.

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

7/30/2019 26118-ssl

9/13

FUOC P03/75070/02123 66 Mecanismos de proteccindepende 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 contrala negociacin esmodificar los mensajespara que las dos partesacuerden utilizar elprotocolo SSL 2.0, que esms vulnerable. Paraevitar este ataque, a losdos primeros bytes delsecreto pre-maestro debehaber el nmero deversin que se envi en elmensaje 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 alsecreto 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) Verificacin de certificado (Certificate Verify)

Si el cliente ha mandado un certificado en respuesta a un mensaje Certifi-

cate Request, ya puede autenticarse demostrando que posee la clave priva-

da correspondiente mediante un mensaje Certificate Verify. Este mensaje

contiene una firma, 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 criptogrficos

negociados. Cada parte manda a la otra una notificacin de cambio de

cifrado seguida de un mensaje Finished. La notificacin 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 notificacin de cambio deVerificacin de

autenticidad en SSL yTLS

Una de las principalesdiferencias entre SSL 3.0y TLS 1.0 est en latcnica usada paraobtener los cdigos deverificacin de losmensajes Finished, ytambin para calcular elsecreto maestro y paraobtener las claves a partirde este secreto (en SSLse utilizan funciones hashdirectamente, 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 Finishedsirve para verificar 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

7/30/2019 26118-ssl

10/13

FUOC P03/75070/02123 67 Mecanismos de proteccinUna 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

7/30/2019 26118-ssl

11/13

FUOC P03/75070/02123 68 Mecanismos de proteccin

A ms de los mensajes de negociacin, notificaciones 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 fin de la conexin y la invalidacin del identificador 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 fin normal de

la conexin. Para evitar ataques de truncamiento, si una conexin acaba sin

haber enviado este aviso se invalidar su identificador 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 sniffing, se enfrenta al problema de romper el cifrado siquiere 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

7/30/2019 26118-ssl

12/13

FUOC P03/75070/02123 69 Mecanismos de proteccinEs 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 necesarioenviar un certificado donde tiene que haber la clave pblica del emisor firmada

por una autoridad de certificacin 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 certificado digital debidamente firmado por la CA sirve para

verificar 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 certificacin que ha emitido el certificado para poder

generar otro con una clave pblica diferente y que parezca autntico.

Alteracin de los paquetes. Un atacante puede modificar los paquetes para

que lleguen al destinatario con un contenido distinto del original (si estn cifra-

dos no podr controlar cual ser el contenido final 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 finalidad por ejemplo de forzar la adopcin

de algoritmos criptogrficos ms dbiles y vulnerables, esta manipulacin serdetectada en la verificacin 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 flujosde la comunicacin se utilizan claves de cifrado y de MAC diferentes.

FUOC XP04/90789/00892

7/30/2019 26118-ssl

13/13

FUOC P03/75070/02123 70 Mecanismos de proteccinComo consideracin final, 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 criptogrficos 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 fin 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 especficos para SSL/TLS (RFC 2595).

Tambin hay definido un mecanismo para negociar el uso de SSL/TLS en

HTTP (RFC 2817), como alternativa a HTTPS.

FUOC XP04/90789/00892