Qu es SSL?
Es el protocolo seguro de comunicacin, que permite autenticacin y privacidad
sobre Internet. Por cosas como stas, podemos entrar a Facebook sin que nadie vea
qu es lo que hacemos aunque est intentando escuchar. Aunque sea as de segura,
le corresponden fallas y agujeros de seguridad, por lo que se ha desarrollado TLS y
hoy en da la actualizacin ms nueva es la 1.2 (implementada desde 2008).
Hablamos de que la 1.0 fue definida en el RFC a principios del '99, as que entiendan
que los estndares duran varios aos.
Algo que me gustara ver, antes de adentrarnos en cuestiones tcnicas, es esto.
Abran sus navegadores y entren a una red social como Twitter o Facebook. Al lado
de la direccin de la web, del lado izquierdo nos aparece un candadito.
Ese candadito es lo que nos dice Ey, esta comunicacin es segura, y adems nos
marca con verde el HTTPS porque estamos en un protocolo seguro para acceder a
la web. Si le damos click al candado (ojo que cada navegador tiene su manera de
visualizar los certificados. Estoy usando Chrome en este caso y se logra acceder con
click derecho), nos encontramos con esto:
1/15
Bueno, tenemos 2 cosas que ver. Primero que un supuesto DigiCert SHA2 blablabla
emiti el certificado y que lo aprueba. Si nos metemos en los datos del
certificado?
Nos aparece todos los datos del mismo. Es decir, el logaritmo usado para el hash de
la firma, la versin, hasta que fecha es vlido e incluso la clave pblica. No se ustedes
pero a mi siempre me pareci muy interesante que este tipo de informacin sea
pblica.
2/15
En la segunda parte nos dice dos cosas que nos importan. La version de TLS (1.2) y
el mecanismo de intercambio de clave simtrica, que es el ECDHE_ECDSA. Esto
corresponde a Curva elptica de Diffie-Hellman - Curva elptica de algoritmo de
firma digital. Aunque creo que por ahora voy a dejar las curvas elpticas y la
generacin de claves para otro da porque merecen una clase entera para ellas solas.
Adems en la ltima clase profundic RSA y me han llegado cartas de amenazas.(?)
3/15
REGISTROS SSL/TLS
Los registros se dividen de esta manera:
1) Campo que indica qu es lo que viene. Un error, datos, cambio en el
protocolo o cambio de cifrado.
2) Versin del protocolo.
3) Longitud del registro, as verifican errores.
4) Datos. Desde aqu, todo lo que va en el registro est cifrado.
5) Cdigo de autenticacin MAC.
MAC? Le enva la direccin de la placa de red, otra vez. Eso no tiene
sentido.
Aqu es distinto. Con MAC, quiero decir Message Authentication Code. No
ahondaremos demasiado en eso. Simplemente es un clculo que se realiza tomando
varios datos del registro que estamos enviando y aplicando una funcin hash. Algo
as como un cdigo de seguridad.
6) Lo dems son bytes de relleno por si se usa alguna tcnica de cifrado en
bloque. Es decir, si cifra de a 8 bytes, pero usamos 30 bytes de datos, entonces
necesitamos poner 2 bytes de relleno para llegar a los 32 y que sea mltiplo
de 8. A esto se lo denomina padding.
7) El ltimo campo nos dice cuntos bytes de padding hay.
4/15
PROTOCOLO DE NEGOCIACION
Como vimos en SSH, examinaremos el protocolo de negociacin de una
comunicacin por SSL. Son 10 etapas importantes para la apertura de un canal
nuevo, o 4 si es un canal que alguna vez ya fue usado. Voy a explicarlas paso por
paso, de a poco.
1. Hello Request: Este mensaje es optativo. Generalmente no sucede, pero el
server puede enviar hacia el cliente un request de inicio de sesin.
2. Client Hello: El cliente enva este mensaje que es el saludo de inicio,
conteniendo: versin del protocolo que quiere usar, una cadena de 32 bytes
aleatorios, lista de algoritmos criptogrficos preferentes, lista de algoritmos
de compresin y (opcionalmente) ID de una anterior sesin para repetir
parmetros. El ID es un nmero identificador.
5/15
3. Server Hello: El servidor recibe el hola inicial del cliente y manda su
respuesta con otro saludo. La informacin contenida es: versin de protocolo
a usar, otra cadena de 32 bytes aleatorios, ID de la sesin actual (en caso de
querer usar las mismas preferencias de un ID anterior enviado por el cliente,
usa el mismo ID), combinacin de algoritmos criptogrficos y de compresin.
En caso de que el server no enve ningn ID es para no dejar que el cliente use
el restablecimiento de la configuracin en una conexin futura.
4. Certificate o Server Key Exchange: Para autenticarse, el server enva este
mensaje Certificate con un certificado X.509 (ms adelante lo
profundizaremos, pero piensen como si fuera una planilla de validacin que
certifica que es l mismo) o una cadena de certificados. Si el servidor no tiene
certificado, o acord un mtodo de intercambio de claves que no lo necesita,
debe mandar un Server Key Exchange. Desde este paso, slo es necesario
para una sesin nueva. Para reemprenderla, no es necesario tanto barullo.
5. Certificate Request: En caso de que el cliente deba decir quin es, entonces el
server le manda este mensaje exigindole que lo certifique.
6. Server Hello Done: Para terminar el dilogo del handshake.
7. Certificate: Si el server le envo un mensaje de Certificate Request, entonces el
cliente se lo enva.
6/15
8. Client Key Exchange: Aqu el cliente enva un contenido de claves como las
claves de cifrado simtrico previamente cifradas con la clave pblica del
servidor. Como vimos en la clase anterior, es posible hacerlo con RSA.
9. Certificate Verify: La idea de este mensaje es que el cliente enve este
mensaje en conjunto con el Certificate para demostrar que fue l quien lo
envo. Cmo? Simple. Firmndolo con su clave privada. Recuerden que si le
aplicamos la clave pblica, entonces verificaremos que es l.
10. Finished: Con este mensaje se completa un handshake exitoso. Desde
aqu se pueden enviar datos uno con el otro.
7/15
8/15
Qu corno es x.509?
Es un estndar. Una manera de cmo estn organizados los datos de los certificados
para que todos lo hagan de una misma manera. En este caso estn organizados as:
Versin
Nmero de serie
ID del algoritmo
Emisor
Fechas de validez
Sujeto (a quin valida)
Clave pblica del Sujeto
Datos opcionales
Algoritmo usado para firmar el certificado
Firma del certificado
Vamos directamente a un ejemplo de un certificado:
9/15
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/[email protected]
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Gracias Wikipedia por el certificate.
En negrita estn remarcados los campos que deben ir. Pero no nos metamos ms en
esto.
10/15
Vulnerabilidades
Cada vez que SSL es vulnerado, la voz se pasa rpidamente y se aprovecha por
muchos internautas curiosos. Pero generalmente el parche se libera al poco tiempo
-relativamente hablando- as que no esperen poder aprovecharse de esto
deliberadamente. Veremos el famoso bug que recorri las noticias informticas en
Abril del 2014: Heartbleed.
La idea es que el handshake que vimos anteriormente es un proceso que no se
quisiera hacer demasiadas veces, porque lleva tiempo y recursos computacionales.
Entonces se cre el HeartBeat (latido del corazn), un mensaje que enva el cliente
al servidor para hacerle saber que an est ah, comunicndose con l. El mensaje
consta de una conversacin parecida a sta:
Cliente: -Ey, server. Ests activo todava? Si es as, responde con la palabra
auto. Son 4 letras.
Servidor: -auto
Si se fijan bien, el cliente dice cuantas letras tiene el mensaje. Claro, en el
intercambio de datos normal estaramos hablando de una longitud en bytes.
Es necesario saber eso?
Bueno, s. Es justamente el fallo. Cuando el cliente dice que da una cantidad de letras
mayor a lo que es la palabra, el server se confunde porque adems de mandar la
11/15
palabra de respuesta, rellena esa cantidad de letras con las que tiene en
memoria en ese momento. Entonces la conversacin pasara a ser algo as:
Cliente: -Ey, server. Ests activo todava? Si es as, responde con la palabra
auto. Son 50 letras.
Servidor: -auto. Perro, caniche. Admin. User. Passwords.....
Claro. Aqu en nuestro ejemplo, el server tiene palabras sueltas pero en la vida real,
en memoria, el server podra tener credenciales, contraseas, logs, informacin de
sistema requerida, acciones de los usuarios, etc.
Me imagino que el registro slo puede mandar una cantidad de datos
limitados.
Y claro. Tiene un limite, de 64KB.
Entonces el fallo es grave pero es difcil de recolectar muchos datos.
En realidad, si fuesen siempre el mismo segmento de memoria no sera una
inmensidad. Pero la verdad es que siempre que se hace un pedido para que el
servidor responda, la direccin de memoria cambia. Esto es igual a poder descargar
GB de memoria en poco tiempo. Imaginen la catstrofe que fue cuando se
descubri.
Lo importante es siempre mantener actualizado el sistema con el cual tenemos
salida a internet :), leer las noticias e intentar de usar sistemas seguros.
12/15
En fin. Eso es todo por hoy :). Espero que lo hayan disfrutado (y aprendido sobre
todo) y nos vemos en la siguiente clase. :D
13/15
-------------------------------------------
Pueden seguirme en Twitter: @RoaddHDC
Para donaciones, pueden hacerlo en bitcoin en la direccin
siguiente:
1HqpPJbbWJ9H2hAZTmpXnVuoLKkP7RFSvw
-------------------------------------------
Este tutorial puede ser copiado y/o compartido en cualquier
medio siempre aclarando que es de mi autora y de mis propios
conocimientos.
-------------------------------------------
Roadd.
14/15
