06/11/2015

Qu es

SSL?

Capa

de Conexiones Seguras. Es un
protocolo que hace uso de certificados
digitales
para
establecer
comunicaciones seguras a travs de
Internet.
Recientemente
ha
sido
sustituido por TLS (Transport Layer
Security) el cual est basado en SSL y
son totalmente compatibles.

PROTOCOLO SSL Y SSL

HANDSHAKE.

SSL (SECURE SOCKETS LAYER)

Te

permite confiar informacin personal a

sitios web, ya que tus datos se ocultan a
travs de mtodos criptogrficos mientras
navegas en sitios seguros.

Es

utilizado ampliamente en bancos, tiendas

en lnea y cualquier tipo de servicio que
requiera el envo de datos personales
o contraseas. No todos los sitios web usan
SSL, por eso debes ser cuidadoso.

SSL (SECURE SOCKETS LAYER)

Firma digital

Del mismo modo que tu firma autgrafa, es un elemento que

te identifica y distingue de las dems personas y que al firmar
con ella adquieres derechos y obligaciones. La firma digital
se genera con base a la llav e priv ada de quien firma y por lo
tanto es nica.

Autoridad Certificadora (AC)

Una Autoridad Certificadora (AC, en ingls CA) es una

entidad confiable que se encarga de garantizar que el
poseedor de un certificado digital sea quien dice ser,
brindando confianza a ambas partes de una comunicacin
segura SSL/TLS.

CONCEPTOS IMPORTANTES DEL

FUNCIONAMIENTO INTERNO DEL SSL/TSL

Cifrado
El

cifrado es el proceso que transforma tu

informacin de manera que no cualquier usuario
pueda entenderla, se realiza con base a un
elemento nico conocido como llave, as nadie,
excepto el poseedor puede leerla.

Llave

pblica y llave privada

Son

un par de llaves digitales asociadas a una

persona o entidad y generadas mediante
mtodos criptogrficos. La llave pblica es usada
para cifrar la informacin.

CONCEPTOS IMPORTANTES DEL

FUNCIONAMIENTO INTERNO DEL SSL/TSL

Certificado Digital SSL/TLS

Es un documento digital nico que garantiza la v inculacin

entre una persona o entidad con su llav e pblica.

Contiene informacin de su propietario como nombre,

direccin, correo electrnico, organizacin a la que
pertenece y su llav e pblica, as como informacin propia
del certificado por mencionar: periodo de v alidez, nmero
de serie nico, nombre de la AC que emiti, firma digital de
la AC cifrada con su llav e priv ada y otros datos ms que
indican cmo puede usarse ese certificado.

CONCEPTOS IMPORTANTES DEL

FUNCIONAMIENTO INTERNO DEL SSL/TSL

06/11/2015

HTTPS

SSL es un protocolo que proporciona privacidad e

integridad entre dos aplicaciones de comunicaciones
utilizando HTTP.

Los datos que circulan en un sentido y otro entre el cliente

y el servidor se cifra mediante un algoritmo simtrico como
DES o RC4. Un algoritmo de clave pblica -generalmente
RSA- se utiliza para el intercambio de las claves de cifrado
y para las firmas digitales. El algoritmo utiliza la clave
pblica en el certificado digital del servidor. Con el
certificado digital del servidor, el cliente tambin puede
verificar la identidad del servidor. Las versiones 1 y 2 del
protocolo SSL slo proporcionan autenticacin de servidor.
La versin 3 agrega la autenticacin del cliente, utilizando
los certificados digitales de cliente y de servidor.

Simplemente

es una combinacin del protocolo

HTTP (usado en cada transaccin web) con el
protocolo
SSL/TLS
usada
para
establecer
comunicaciones cifradas en sitios web.

CONCEPTOS IMPORTANTES DEL

FUNCIONAMIENTO INTERNO DEL SSL/TSL

Supongamos

que intentas acceder al sitio de

Facebook de forma segura, es decir, usando
https en la direccin web. Inmediatamente,
aparecer la pgina en pantalla y en alguna
parte de tu navegador observars un
candado, dependiendo del navegador
que uses. Si no viste ningn mensaje de
advertencia (generalmente en tonos rojos), el
protocolo SSL/TLS ha hecho su trabajo.

En el punto dos del Diagrama 1, cuando el navegador

hace una peticin al sitio seguro de Facebook, ste enva
un mensaje donde indica que quiere establecer una
conexin segura y enva datos sobre la versin del
protocolo SSL/TLS que soporta y otros parmetros
necesarios para la conexin.

En base a esta informacin enviada por el navegador, el

servidor web de Facebook responde con un mensaje
informando que est de acuerdo en establecer la
conexin segura con los datos de SSL/TLS proporcionados.

Una vez que ambos conocen los parmetros de conexin,

el sitio de Facebook presenta su certificado digital al
navegador web para identificarse como un sitio confiable.

INICIANDO COMUNICACIN SEGURA

FUNCIONAMIENTO

SSL/TLS funciona de forma transparente para ti, lo que en realidad

ocurre cuando intentas acceder a un sitio seguro se asemeja al
siguiente diagrama.

Una

vez que el navegador tiene el certificado

del sitio web de Facebook, realiza algunas
verificaciones antes de confiar en el sitio:

Integridad

del certificado: Verifica que el

certificado se encuentre ntegro, esto lo hace
descifrando la firma digital incluida en l
mediante la llave pblica de la AC y
comparndola con una firma del certificado
generada en ese momento, si ambas son
iguales entonces el certificado es vlido.

VERIFICACIN DE VALIDEZ DEL

CERTIFICADO

06/11/2015

Vigencia del certificado: Revisa el periodo de validez

del certificado, es decir, la fecha de emisin y la
fecha de expiracin incluidos en l.

Verifica emisor del certificado: Hace uso de una lista

de
Certificados
Raz
almacenados
en
tu
computadora y que contienen las llaves pblicas de
las ACs conocidas y de confianza. Con base a esta
lista, el navegador revisa que la AC del certificado
sea de confianza, de no serlo, el navegador mostrar
una advertencia indicando que el certificado fue
emitido por una entidad en la cual no confa.

Un

caso real que ejemplifica el mal uso de

esta tecnologa fue publicado en el artculo
Troyano bancario secuestra conexiones SSL,
el
cual
puedes
consultar
en http://www.seguridad.unam.mx/noticias/?
noti=4419. En este artculo se detalla un
troyano (Trojan.Tatanarg) capaz de secuestrar
conexiones SSL/TLS al momento de realizar
transacciones bancarias en lnea. A grandes
rasgos lo que hace este troyano es:

CASO DE VULNERABILIDAD
VERIFICACIN DE VALIDEZ DEL
CERTIFICADO

Supongamos

que deseas realizar una operacin

bancaria en lnea. Al ingresar a la pgina web
de tu banco, durante el proceso de conexin
SSL/TLS, el banco enva a tu navegador su
certificado y su llave pblica firmados, elementos
que utilizar para cifrar la informacin a
transmitir. El troyano se interpone entre el servidor
del banco y tu navegador tomando la llave
pblica y la informacin del certificado para
cifrar su propio canal de comunicacin, mientras
tanto, del lado del navegador el troyano inserta
su certificado auto-firmado (certificado falso) de
tal manera que el candadito de seguridad
siempre est visible durante la conexin y as la
presencia del troyano resulta imperceptible.

Cuando env as tu informacin al banco, sta es cifrada

utilizando el certificado falso e interceptada por el mismo
troyano, quien la manipula y transfiere al banco para que ste la
procese.

Empleando el certificado falso, el troyano es capaz de descifrar

y leer la informacin que compartas con el banco, posiblemente
reenv indola a un atacante para que ste haga mal uso de
ella, por ejemplo robando tu identidad.

HTTP-based SSL connection is

always initiated by the client using a
URL starting with https:// instead of
with http://. At the beginning of an
SSL session, an SSL handshake is
performed.
This
handshake
produces
the
cryptographic
parameters of the session.

SSL HANDSHAKE.

06/11/2015

1.- The client sends a client "hello" message that lists the cryptographic
capabilities of the client (sorted in client preference order), such as the
version of SSL, the cipher suites supported by the client, and the data
compression methods supported by the client. The message also
contains a 28-byte random number.

4.- The serv er sends a serv er "hello done" message and waits for a
client response.

5.- Upon receipt of the serv er "hello done" message, the client (the
Web browser) v erifies the v alidity of the serv er's digital certificate and
checks that the serv er's "hello" parameters are acceptable.

2.-The server responds with a server "hello" message that contains the
cryptographic method (cipher suite) and the data compression
method selected by the server, the session ID, and another random
number.

Note:The client and the serv er must support at least one common cipher suite, or
else the handshake fails. The serv er generally chooses the strongest common
cipher suite.

3.- The server sends its digital certificate. (In this example, the server uses
X.509 V3 digital certificates with SSL.).

If the serv er uses SSL V3, and if the serv er application (for example, the Web serv er)
requires a digital certificate for client authentication, the serv er sends a "digital
certificate request" message. In the "digital certificate request" message, the
serv er sends a list of the types of digital certificates supported and the
distinguished names of acceptable certificate authorities.

Note: An additional process to verify the server digital

certificate is not necessary. If the server does not have the
private key that belongs to the digital certificate, it cannot
decrypt the pre-master secret and create the correct keys
for the symmetric encryption algorithm, and the handshake
fails.

7.- The client uses a series of cryptographic operations to

convert the pre-master secret into a master secret, from
which all key material required for encryption and message
authentication is derived. Then the client sends a "change
cipher spec" message to make the server switch to the
newly negotiated cipher suite. The next message sent by
the client (the "finished" message) is the first message
encrypted with this cipher method and keys.

8.- The server responds with a "change cipher spec" and a

"finished" message of its own.

9.- The SSL handshake ends, and encrypted application

data can be sent.

If the serv er requested a client digital certificate, the client sends

a digital certificate, or if no suitable digital certificate is av ailable,
the client sends a "no digital certificate" alert. This alert is only a
warning, but the serv er application can fail the session if client
authentication is mandatory.

6.- The client sends a "client key exchange" message. This message
contains the pre-master secret, a 46-byte random number used in the
generation of the symmetric encryption keys and the message
authentication code(MAC) keys, encrypted with the public key of the
serv er.

If the client sent a digital certificate to the serv er, the client sends
a "digital certificate v erify" message signed with the client's priv ate
key. By v erifying the signature of this message, the serv er can
explicitly v erify the ownership of the client digital certificate.

https://support.microsoft.com/es-es/kb/257591

http://rev ista.seguridad.unam.mx/numero-10/el-cifrado-web-ssltls

https://publib.boulder.ibm.com/tiv idd/td/TRM/SC23-482200/es_ES/HTML/user277.htm

http://www.ajpdsoft.com/modules.php?name=Encyclopedia&o
p=content&tid=822

http://publib.boulder.ibm.com/tiv idd/td/ITAME/SC32-136300/en_US/HTML/ss7aumst18.htm

REFERENCIAS