Práctica de laboratorio: Almacenes de autoridades emisoras de
certificados
Objetivos
Parte 1: Certificados en los que confían sus navegadores
Parte 2: Buscar ataques de intermediarios
Antecedentes / Escenario
Con la evolución de la web, también aumentó la necesidad de medidas de seguridad. HTTPS (la ‘S’ quiere
decir seguridad), junto con el concepto de Autoridad emisora de certificados, fue presentado por Netscape
allá por el año 1994 y sigue utilizándose actualmente. En esta práctica de laboratorio:
• Generarán todos certificados en los que confían sus navegadores (lo harán en sus computadoras).
• Utilizarán hashes para detectar si sus conexiones a Internet están siendo interceptadas (lo harán en la
VM CyberOps)
Recursos necesarios
• VM CyberOps Workstation
• Acceso a Internet
Parte 1: Certificados en los que confían sus navegadores
HTTPS depende de una entidad externa para la validación. Conocida como Autoridad emisora de
certificados (Certification Authority, CA), esta entidad externa verifica si un nombre de dominio realmente
pertenece a la organización que asevera ser su titular. Si la verificación es positiva, la CA crea un certificado
con firma digital que contiene información sobre la organización, incluida su clave pública.
Todo el sistema se basa en el hecho de que los navegadores web y los sistemas operativos se envían con
una lista de CA de confianza. El navegador considerará como legítimo cualquier certificado firmado por
cualquiera de las CA de la lista y confiarán en él automáticamente. Para fortalecer la seguridad y
escalabilidad del sistema, las CA a menudo distribuyen la tarea de creación y firma de certificados en
muchas CA secundarias. La CA principal se conoce como CA raíz. Si un navegador confía en una CA raíz,
también confía todas sus CA secundarias.
Nota: Si bien los almacenes de certificados son similares en todos los navegadores, en esta práctica de
laboratorio nos enfocamos en Chrome 56 y Firefox 59. El menú y los gráficos pueden ser diferentes en otras
versiones de los navegadores web.
Sigan los pasos para mostrar el almacén de CA en sus navegadores:
Paso 1: Mostrar los certificados raíz en Chrome
Puede realizar este paso en el equipo local o utilizar FireFox en la VM CyberOps Workstation. Si utilizan
Firefox, sigan con el Paso 2. Si no utilizan Chrome ni Firefox, busquen los pasos para mostrar sus
certificados raíz en Internet.
Nota: El menú y los gráficos pueden ser diferentes en otras versiones del navegador Chrome.
a. Abran el navegador web Chrome en sus PC.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
b. Hagan clic en el icono de los tres puntos que se encuentra en el extremo derecho de la barra de
direcciones para mostrar las opciones de Chrome.
c. Haga clic en Configuración y, luego, en Mostrar configuración avanzada.
d. Desplácese hacia abajo por la página y haga clic en el botón Administrar certificados…, en la
sección HTTPS/SSL.
e. En la ventana de Certificados que se abre, seleccionen la ficha Autoridades de certificación raíz de
confianza. Se abrirá una ventana con todos los certificados y las autoridades emisoras de certificados
en las que confía Chrome.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Paso 2: Mostrar los certificados en el Almacén de CA en Firefox
Nota: El menú y los gráficos pueden ser diferentes en otras versiones del navegador Firefox y en diferentes
sistemas operativos. En este paso se muestra Firefox 59 en la VM CyberOps Workstation.
a. Abran Firefox y hagan clic en el icono del Menú. El icono de Menú se encuentra en el extremo derecho
de la ventana de Firefox, al lado de la barra de direcciones.
b. Haga clic en Preferencias > Privacidad y seguridad.
c. Desplácese hasta la sección Seguridad y haga clic en Ver certificados.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
d. Se abrirá una ventana con todos los certificados y las autoridades de certificación en las que confía
Firefox.
Parte 2: Buscar ataques de intermediarios
Esta parte se realiza con la VM CyberOps Workstation.
Una de las utilidades de los hashes es verificar la integridad de los datos; pero también se pueden usar para
detectar ataques de intermediarios (o Man-in-the-Middle) en HTTPS.
Para proteger los datos de los usuarios, cada vez más sitios web están adoptando el tráfico cifrado.
Conocido como HTTPS, los sitios utilizan protocolos como TLS/SSL para cifrar el tráfico de los usuarios de
extremo a extremo. Después de cifrar el tráfico correctamente es muy difícil que cualquier tercero que no sea
el usuario o el sitio en cuestión vea el contenido del mensaje cifrado. Esto es bueno para los usuarios pero
crea un problema para las organizaciones que quieren ver el contenido de ese tráfico. Las empresas y las
organizaciones a menudo optan por espiar el tráfico generado por sus empleados para controlarlos.
Necesitaban poder ver el contenido del tráfico cifrado TLS/SSL. Esto se hace por medio de un proxy HTTPS.
Los navegadores web confían en la identidad de un sitio web que se visita si el certificado que presenta ese
sitio web está firmado por una de las CA instaladas en el almacén de certificados del navegador. Para poder
espiar el tráfico cifrado TLS/SSL de sus usuarios, una empresa u organización simplemente agrega otra CA
a la lista de CA instaladas del navegador del usuario.
Consideren la siguiente situación hipotética: la Empresa X contrata a un empleado nuevo y le entrega una
computadora portátil nueva de la empresa. Antes de hacerlo, el departamento de TI de la empresa instala
todo el software necesario para el trabajo. Entre el software y los paquetes que se instalan, el departamento
de TI también incluye una CA adicional a la lista de CA de confianza. Esta CA adicional apunta a una
computadora controlada por la empresa conocida como el proxy HTTPS. Como la empresa controla los
patrones de tráfico, el proxy HTTPS se puede ubicar en el medio de cualquier conexión. Funciona de la
siguiente manera:
1. El usuario trata de establecer una conexión segura al sitio web HTTPS H, alojado en Internet. H puede
ser cualquier sitio HTTPS: un banco, una tienda en línea, un servidor de correo electrónico, etc.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
2. Como la empresa controla los patrones de tráfico, lo hace de modo que todo el tráfico del usuario deba
pasar por el proxy HTTPS. Entonces, el proxy HTTP se hace pasar por el sitio web H y presenta un
certificado firmado automáticamente para demostrar que es H. Esencialmente, el proxy HTTPS dice:
“Hola, soy un sitio HTTPS H. Este es mi certificado. Fue firmado por… mí mismo”.
3. Como el certificado presentado está firmado por una de las CA incluidas en el almacén de CA de la
computadora portátil (recuerden que el departamento de TI la agregó), el navegador web cree
erróneamente que de hecho se está comunicando con H. Observen que, de no haberse agregado la CA
adicional al almacén de CA, la computadora portátil no confiaría en el certificado y se daría cuenta
inmediatamente de que alguien más estaba tratando de hacerse pasar por H.
4. La computadora portátil confía en la conexión y establece un canal seguro con el proxy HTTPS, porque
cree erróneamente que se está comunicando en forma segura con H.
5. Entonces, el proxy HTTPS establece una segunda conexión a H, el sitio web al que el usuario estaba
tratando de acceder desde el comienzo.
6. Ahora, el proxy HTTPS es el punto extremo de dos conexiones seguras individuales; una establecida con
el usuario y la otra con H Como el HTTPS es el punto extremo de ambas conexiones, ahora puede
descifrar tráfico proveniente de las dos.
7. Ahora el proxy HTTPS puede recibir tráfico del usuario cifrado con TLS/SSL destinado a H, descifrarlo,
inspeccionarlo, volver a cifrarlo con TLS/SSL y enviarlo a H. Cuando H responde, el proxy HTTPS
invierte el proceso antes de reenviar el tráfico al usuario.
Observen que el proceso pasa desapercibido para el usuario, que ve la conexión como cifrada con TLS/SSL
(tildes de color verde en el navegador). Si bien la conexión es segura (cifrada con TLS/SSL), se la estableció
con un sitio web falso.
Incluso si su presencia pasa desapercibida para el usuario, los proxis TLS se pueden detectar fácilmente con
la ayuda de hashes. Si consideramos el ejemplo anterior, como el proxy HTTPS no tiene acceso a las claves
privadas de H, el certificado que le presenta al usuario difiere del que presenta H. En cada certificado se
incluye un valor conocido como huella digital. En esencia, una huella digital es un hash calculado y firmado
por el emisor del certificado que actúa como un resumen único de todo el contenido del certificado. Si se
modifica al menos una de las letras del certificado, la huella digital generará un valor completamente
diferente al calcularla. Debido a esta propiedad, las huellas digitales se utilizan para comparar certificados
rápidamente. Si volvemos al ejemplo anterior, el usuario puede solicitar el certificado de H y compara la
huella digital que contiene con la provista al establecer la conexión con el sitio web H. Si las huellas digitales
coinciden, la conexión realmente se estableció con H. Si no coinciden, la conexión se estableció con algún
otro punto extremo.
Sigan los pasos que se indican a continuación para determinar si hay un proxy HTTPS en sus conexiones.
Paso 1: Recopilar la huella digital del certificado correcta y no modificada
a. El primer paso es recopilar algunas huellas digitales de sitios. Estos es importante porque se las utilizará
para compararlas más adelante. La siguiente tabla contiene las huellas digitales de los certificados de
algunos sitios populares.
Nota: Es posible que las huellas digitales de SHA-1 que se muestran en la Tabla 1 ya no sean válidas debido
a que las organizaciones renuevan sus certificados regularmente. La huella digital también se llama huella
dactilar en máquinas basadas en Windows.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Tabla 1: Sitios populares y las huellas digitales de sus certificados SHA-1
Sitio Dominios Huella digital de certificado SHA-1
cubiertos por el (a partir de abril de 2018)
certificado
www.cisco.com www.cisco.com 64:19:CA:40:E2:1B:3F:92:29:21:A9:CE:60:7D:C9:0C:39:B5:71:3E
www.facebook.com *.facebook.com BD:25:8C:1F:62:A4:A6:D9:CF:7D:98:12:D2:2E:2F:F5:7E:84:FB:36
www.wikipedia.org *.wikipedia.org 4B:3E:D6:B6:A2:C7:55:E8:56:84:BE:B1:42:6B:B0:34:A6:FB:AC:24
twitter.com twitter.com 26:5C:85:F6:5B:04:4D:C8:30:64:5C:6F:B9:CF:A7:D2:8F:28:BC:1B
www.linkedin.com www.linkedin.com 3A:60:39:E8:CE:E4:FB:58:87:B8:53:97:89:8F:04:98:20:BF:E3:91
¿Qué son las huellas digitales? ¿Por qué son importantes?
Respuesta: La huella digital es un concepto que incorpora todos los registros y rastros que dejamos
cuando utilizamos internet. En la mayoría de los casos son beneficiosos para el usuario, pero en otras
pueden ser realmente perjudiciales ya que nunca son irrelevantes. Estos registros representan información
sobre nosotros que pueden servir a terceros para ganar dinero o bien conocer nuestras preferencias y
poder vender mejor sus productos.
¿Quién calcula las huellas digitales? ¿Cómo se las encuentra?
Respuesta: existen 3 principales tipos de entidades que son los anunciantes, los editores y los
agregadores; los anunciantes son empresas que venden algún tipo de producto o servicio, los editores son
aquellos que publican avisos en línea que buscan combinar los anuncios con el contenido de las paginas
web que consultamos frecuentemente, los agregadores recopilan la información anónima de sus socios y
la reutilizan para dirigirlos anuncios al publico apropiado.
Ahora bien, estos datos se encuentran cuando navegamos y/o visitamos una página web ya que estamos
entregando una información concreta al dueño de la página web. Primero que todo nuestra IP, que revela
la ubicación geográfica, además nuestra ubicación geográfica, navegador, sistema operativo del ordenador
o dispositivo, idioma, sexo, edad, e incluso el último lugar que hemos visitado, a su vez, dejan una cadena
de dígitos en nuestro navegador que se conoce como cookie.
Paso 2: Recoger la huella digital del certificado que está utilizando la VM CyberOps
Workstation
Ahora que tenemos las huellas digitales reales, es momento de obtener huellas de un host local y comparar
los valores. Si las huellas digitales no coinciden, el certificado en uso NO pertenece al sitio HTTPS que se
está verificando, lo que significa que hay un proxy HTTPS entre el servidor y el sitio HTTPS en cuestión. Si
las huellas digitales coinciden, no hay ningún proxy HTTP.
a. Utilicen los siguientes tres comandos canalizados para obtener la huella digital correspondiente a
Cisco.com. En la línea de abajo se utiliza OpenSSL para conectarse con cisco.com en el
puerto 443 (HTTPS), solicitar el certificado y almacenarlo en un archivo de texto de nombre cisco.pem.
También se muestra la salida para ofrecer contexto.
[analyst@secOps ~]$ echo -n | openssl s_client -connect cisco.com:443 | sed
-ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ./cisco.pem
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
verify return:1
depth=1 C = US, O = HydrantID (Avalanche Cloud Corporation), CN = HydrantID SSL ICA G2
verify return:1
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
depth=0 C = US, ST = CA, L = San Jose, O = "Cisco Systems, Inc.", CN = www.cisco.com
verify return:1
LISTO
b. De manera opcional, utilicen el comando cat para generar una lista con el contenido del certificado
obtenido y almacenarlo en el archivo de texto cisco.pem:
[analyst@secOps ~]$ cat cisco.pem
-----BEGIN CERTIFICATE-----
MIIG1zCCBL+gAwIBAgIUKBO9xTQoMemc9zFHNkdMW+SgFO4wDQYJKoZIhvcNAQEL
BQAwXjELMAkGA1UEBhMCVVMxMDAuBgNVBAoTJ0h5ZHJhbnRJRCAoQXZhbGFuY2hl
IENsb3VkIENvcnBvcmF0aW9uKTEdMBsGA1UEAxMUSHlkcmFudElEIFNTTCBJQ0Eg
RzIwHhcNMTcxMjA3MjIxODU1WhcNMTkxMjA3MjIyODAwWjBjMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExETAPBgNVBAcMCFNhbiBKb3NlMRwwGgYDVQQKDBNDaXNj
byBTeXN0ZW1zLCBJbmMuMRYwFAYDVQQDDA13d3cuY2lzY28uY29tMIIBIjANBgkq
yvo6dWpJdSircYy8HG0nz4+936+2waIVf1BBQXZUjNVuws74Z/eLIpl2c6tANmE0
q1i7fiWgItjDQ8rfjeX0oto6rvp8AXPjPY6X7PT1ulfhkLYnxqXHPETRwr8l5COO
MDEh95cRxATXNAlWAwLcBT7lDmrGron6rW6hDtuUPPG/rjZeZbNww5p/nT3EXX2L
Rh+m0R4j/tuvy/77YRWyp/VZhmSLrvZEYiVjM2MgCXBvqR+aQ9zWJkw+CAm5Z414
Eiv5RLctegYuBUMGTH1al9r5cuzfwEg2mNkxl4I/mtDro2kDAv7bcTm8T1LsZAO/
1bWvudsrTA8jksw+1WGAEd9bHi3ZpJPYedlL
-----END CERTIFICATE-----
[analyst@secOps ~]$
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
c. Ahora que el certificado está guardado en el archivo de texto cisco.pem, utilicen el siguiente comando
para extraer su huella digital y mostrarla en la pantalla:
[analyst@secOps ~]$ openssl x509 -noout -in cisco.pem -fingerprint -sha1
SHA1 Huella digital = 64:19:CA:40:E2:1B:3F:92:29:21:A9:CE:60:7 D: C9:0 C: 39:B5:71:3E
[analyst@secOps ~]$
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Nota: El valor de la huella digital puede ser diferente por dos motivos. En
primer lugar, es posible que esté utilizando un sistema operativo diferente a
la VM CyberOps Workstation. En segundo lugar, los certificados se actualizan
con regularidad y cambian así el valor de la huella digital.
¿Qué algoritmo de hash utilizó OpenSSL para calcular la huella digital?
Respuesta: El algoritmo implementado fue el sha1
¿Por qué se eligió ese algoritmo específico? ¿Tiene alguna importancia?
Respuesta: Porque es la base de las firmas digitales y es importante porque es normalmente utilizado en
procesos de validación de identidad
Paso 3: Comparar las huellas digitales
Utilicen la Tabla 1 para comparar la huella digital del certificado que se obtuvo directamente desde el
sitio HTTPS de Cisco con la que se obtuvo desde sus redes. Recuerde que las huellas digitales pueden
cambiar con el tiempo.
¿Coinciden las huellas dactilares?
Respuesta: De acuerdo a la tabla 1 la huella digital que se obtuvo es
64:19:CA:40:E2:1B:3F:92:29:21:A9:CE:60:7D:C9:0C:39:B5:71:3E y la que obtuvimos es
EE:DA:31:F4:B8:31:0F:1A:E9:9E:2E:B7:ED:AB:0C:CF:AF:24:8E:04 por lo tanto no coinciden.
¿Qué significa eso?
Respuesta: La huella digital a tenido cambios ya que la que esta en la tabla 1 es del 2018 y la obtenida
es del 2020 y durante este tiempo es posible que la pagina web consultada allá tenido cambios por lo
que la huella dactilar también puede sufrir dichos cambios
¿Es este método 100 % infalible?
Respuesta: a nuestra consideración no es 100% infalible ya que existen diferentes métodos para
obtener una huella digital
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Parte 3: Desafíos (opcionales)
a. Comprueben las huellas digitales correspondientes a los sitios que se ven en la Tabla 1, pero utilizando
la GUI de sus navegadores web.
Pistas: Busque una manera de mostrar la huella digital a través de la GUI del navegador. Recuerde:
Google les resultará útil en este ejercicio, y Windows a menudo llama huella digital a la Huella digital.
Consultando la página de www.facebook.com obtenemos la huella digital que está en el recuadro rojo.
Consultando la página de www.wikipedia.org obtenemos la huella digital que está en el recuadro rojo.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Consultando la página de twitter.com obtenemos la huella digital que está en el recuadro rojo.
Consultando la página de www.linkedin.com obtenemos la huella digital que está en el recuadro rojo.
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
b. Utilicen OpenSSL (Parte 2, pasos 1 al 3) para comprobar todas las huellas digitales que figuran en la
Tabla 1.
Utilizando OpenSSL para Facebook para la huella digital se obtiene:
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Utilizando OpenSSL para Wikipedia para la huella digital se obtiene:
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Utilizando OpenSSL para Twitter para la huella digital se obtiene:
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Utilizando OpenSSL para LinkedIn para la huella digital se obtiene:
Práctica de laboratorio: Almacenes de autoridades emisoras de certificados
Reflexión
¿Qué necesitaría para que funcione el proxy HTTPS?
Respuesta: Puede utilizar el proxy HTTPS para asegurar un servidor web para examinar el tráfico HTTPS
solicitado por clientes en su red. De forma predeterminada, cuando el cliente HTTPS inicia una solicitud,
establece una conexión del TCP(Protocolo de Control de Transmisión) en el puerto 443. La mayoría de los
servidores HTTPS detectan solicitudes en el puerto 443
Estos servidores proxy pueden interpretar el tráfico de red, por lo que se utilizan para almacenar en caché
páginas web y archivos, lo que facilita y agiliza el acceso a ellos por parte de los usuarios.
Los proxies HTTP pueden afectar a múltiples conexiones al mismo tiempo sin que sus velocidades se vean
afectadas. Sin embargo, toda esa velocidad tiene un costo, es decir, una falta completa de encriptado.