9.2.2.7 Práctica de laboratorio: Almacenes de autoridades emisoras de certificados

Última actualización: octubre 17, 2022

9.2.2.7 Práctica de laboratorio: Almacenes de autoridades emisoras de certificados (versión para el instructor)

Nota para el instructor: Los elementos con color de fuente rojo o resaltados en gris indican texto que aparece solo en la copia del instructor.

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.

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.

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.

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.
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
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.

Tabla 1: Sitios populares y las huellas digitales de sus certificados SHA-1

Sitio	Dominios cubiertos por el certificado	Huella digital de certificado SHA-1 (a partir de abril de 2018)
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?
Una huella digital de certificado es un hash que se calcula con el certificado. Es importante porque representa una forma rápida de comprobar si se manipuló información en el certificado.

¿Quién calcula las huellas digitales? ¿Cómo se las encuentra?
Generalmente la autoridad emisora de certificados que firma el certificado es la que calcula la huella digital de certificado. Después de que haya sido computada, la autoridad emisora de certificados la incluye en el certificado. La huella digital puede mostrarse fácilmente al visualizar el certificado.

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
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 ~]$

c. Ahora que el certificado está guardado en el archivo de texto 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 ~]$

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?
SHA-1

¿Por qué se eligió ese algoritmo específico? ¿Tiene alguna importancia?
Las huellas digitales que se adquieren y se muestran en la tabla son todas SHA-1. Cualquier otro algoritmo utilizado por OpenSSL al calcular la huella digital produciría un hash diferente y, por lo tanto, una huella digital diferente, lo que invalidaría la prueba.

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?
Las respuestas variarán dependiendo de la red que se esté utilizando. Si están usando la máquina virtual como se indica, la respuesta es Sí; lo más probable es que la máquina virtual no tenga una autoridad emisora de certificados falsa instalada en su tienda.

¿Qué significa eso?
Las respuestas variarán dependiendo de la red que se esté utilizando. Si las huellas dactilares coinciden, es probable que no se haya manipulado el certificado y, por lo tanto, no existe un proxy HTTPS en funcionamiento; el tráfico que se intercambia entre la máquina local y el sitio cisco.com está completamente encriptado. Cuando las huellas digitales no coinciden se debe a que otra persona interceptó la conexión, envió su propio certificado a la máquina host y estableció una nueva conexión SSL/TLS con cisco.com, ubicándose en el medio. Ya que se envió un nuevo certificado a la máquina local, la huella digital de ese nuevo certificado es diferente al certificado utilizado por cisco.com. El proxy HTTPS puede leer el tráfico entre la máquina local y el sitio cisco.com.

¿Es este método 100 % infalible?
No. Si bien las huellas dactilares que no coinciden comunican la interceptación del tráfico SSL/TLS, las huellas dactilares que coinciden deben manejarse con cuidado. Algunas excepciones a tener en cuenta son: 1. Es probable que la máquina virtual de CyberOps Workstation NO tenga instalados certificados raíz de una autoridad emisora de certificados de la empresa. En ese escenario, es posible que la máquina virtual no intercepte su tráfico, mientras que otras máquinas de la red local, sí. 2. La empresa podría utilizar reglas dinámicas para interceptar solamente sitios seleccionados.

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.

b. Utilicen OpenSSL (Parte 2, pasos 1 al 3) para comprobar todas las huellas digitales que figuran en la Tabla 1.

Reflexión

¿Qué necesitaría para que funcione el proxy HTTPS?

El equipo local tendría que confiar ciegamente en el proxy HTTPS. Las empresas y organizaciones que desean monitorear el tráfico HTTPS logran esta confianza al instalar el certificado del proxy HTTPS en el almacén de certificados raíz del equipo local. En este escenario, las máquinas locales confiarán en el proxy HTTPS, lo que le permite descifrar el tráfico sin advertencias.