AyGR - TLS - OpenSSL - Certificados Digitales X.509 / OpenSSH

Fecha de Entrega: Chivilcoy 11/11/2024. Luján 11/11/2024.

Objetivo: Conocer dos casos de aplicación de varios tipos de cifrados. Reconocer mecanismos de intercambio de clave y familiarizarse con las tecnologías que permiten operar una Infraestructura de Clave Pública (PKI). Entender el concepto de certificado en el contexto de TLS / HTTPS y su funcionamiento. Conocer herramientas y mecanismos para generar y administrar certificados ITU-T X.509, los procedimientos de solicitud, firma e implementación. Acercamiento a SSH. Categorías ISO: FCAPS.

Bibliografía

  • STALLINGS, W. 2014. Capítulo 14: Key Management and Distribution en Cryptography and Network Security - Principles and Practice (6th ed). Pearson Education Inc.
  • STALLINGS, W. 2014. Capítulo 17: Transport-Level Security en Cryptography and Network Security - Principles and Practice (6th ed). Pearson Education Inc.
  • GORALSKI, W. 2017. Capítulo 27: “Securing Sockets with SSL” en The Illustrated Network: How TCP/IP Works in a Modern Network (2nd ed). Morgan Kaufmann.
    https://www.sciencedirect.com/science/book/9780128110270
  • DRISCOLL, M. 2018. The Illustrated TLS Connection - Every byte of a TLS connection explained and reproduced - https://tls.ulfheim.net/
  • DRISCOLL, M. 2018. Server Certificate Detail - https://tls.ulfheim.net/certificate.html
  • COOPER, D., et al. 2008. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280.

Experiencia de laboratorio

Certificados digitales

  1. Acceda a los siguientes sitios: https://webmail.unlu.edu.ar/, https://gitlab.com/help, https://www.google.com.ar/. A través de las herramientas de desarrollador (en Chrome y Firefox) obtenga los certificados y analice la jerarquía de certificados (Certificate Hierarchy).

    1. ¿Que entidades emitieron tales certificados? ¿Cuál es el orden de jerarquía?
      ¿Hay alguna coincidencia en la jerarquía de los certificados de los sitios visitados?

    2. Para el certificado de la web de la universidad (*.unlu.edu.ar) detalle: el algoritmo de firma utilizado, el período de validez del certificado, el sujeto (subject), el emisor (issuer) y la copia de la clave pública del servidor.

    3. ¿Qué significa la sección “Nombre alternativo del sujeto del certificado”? ¿Para qué puede utilizarse? ¿Qué valores poseen los certificados de UNLu y de Google?

  2. Ingrese al sitio web https://badssl.com/ donde se recopila una serie de situaciones que pueden suceder en el contexto de HTTPS y los certificados provistos. Con el acompañamiento docente, examine los diferentes sitios que están linkeados allí y determine los errores que subyacen a las fallas presentadas en el sitio.

  3. Genere un certificado auto-firmado para un sitio web alojado en su propia dirección IP. Configure un servidor web Apache que lo utilice (ver anexo). Acceda mediante un navegador a su sitio web utilizando HTTPS. ¿Qué significa el mensaje de error que presenta el navegador?

  4. En lugar de utilizar el certificado auto-firmado, solicite al equipo docente que procese su solicitud de firma de certificado (CSR). Instale el nuevo certificado en el servidor web y repita la consulta. ¿Qué cambió? ¿Es posible evitar que el navegador presente la advertencia?

  5. Utilice el comando openssl para obtener el certificado desde su servidor web y almacenarlo en un archivo denominado cert_servidor_laboratorio.txt

     $ openssl s_client -connect IP_SERVIDOR:PUERTO

  6. Realice una captura al momento de realizar una consulta a un servidor web en el laboratorio. Guarde esta captura bajo el nombre cap-ejer-ssl.pcap

SSH

El Secure Shell Protocol, más conocido como SSH, es un esquema de arquitectura cliente/servidor que crea un canal seguro de comunicación entre dos dispositivos sobre una red insegura. Se vale de técnicas de autenticación y cifrado mediante claves tanto simétricas como asimétricas.

El caso de uso más común es cuando un usuario se quiere conectar desde un host a la terminal de un servidor o router en un lugar distante. Para ello inicia una conexión con un cliente SSH que se comunica con el servidor que tiene un servicio de SSH activo. El servidor le solicitará la contraseña para el usuario que se desea comunicar.

Además de la funcionalidad de ejecución de comandos en forma remota (inicio de sesión y login remoto), el protocolo SSH sienta las bases para otros protocolos que operan sobre él, sin requerir servicios ni puertos adicionales en escucha en el sistema.

Sobre la infraestructura que proporciona el protocolo ssh se pueden utilizar diferentes utilidades:

  • Acceso a shell (terminal) remota con el comando ssh.
  • Copia de archivos desde/hacia host remotos con el comando scp.
  • Servicio ftp con el comando sftp.
  • Servicio de file system remoto con sshfs.
  • Creación de túneles para acceder a puertos en máquinas remotas, con el comando ssh.

Como ha sido mencionado, este protocolo funciona con arquitectura cliente/servidor. Por lo general, todas las distribuciones de linux actuales tienen el cliente ssh instalado. Con este cliente será posible conectarse de forma remota a cualquier servidor, router o computadora que tenga un servidor ssh en escucha.

Elija dos equipos en los que tenga dominio de administración y que se encuentren conectados por una red (puede utilizar máquinas virtuales). El equipo donde usaremos el comando ssh lo llamaremos “local” y al equipo al cual nos conectaremos lo llamaremos “remoto”.

  1. El puerto bien conocido de SSH es el TCP 22. Verifique que el equipo remoto tenga un servicio ssh corriendo utilizando el comando netstat -plunt (paquete net-tools). Este comando le mostrara los puertos y el estado de los mismos en la máquina en que lo ejecute. Por cierto, ¿cómo podría saber si otro equipo que no sea el suyo tiene un servidor ssh corriendo?

    Si no encuentra ningún puerto en estado LISTEN en el puerto 22, significa que probablemente no tenga instalado el servidor ssh. Si ese es el caso, instale en el host remoto el paquete openssh-server. Verifique el estado del servicio con sudo systemctl status ssh.

  2. Vamos ahora a conectarnos desde el equipo “local” hasta el equipo “remoto”. Para ello escribiremos desde el equipo local ssh USER@IP-REMOTO. USER en este caso corresponde a un usuario válido del equipo remoto (el cual usted tiene su contraseña). Cuando se intente conectar por primera vez aparecerá el siguiente mensaje en consola:

    The authenticity of host 'IP-REMOTO(IP-REMOTO)' can't be established.
ECDSA key fingerprint is SHA256:nCnddHUI5D6a1/DVQSJhQ5BqyURE64kxOcJ1QyIlKloY.
Are you sure you want to continue connecting (yes/no)?

    El servidor remoto, tiene su propio par de claves para utilizar en criptografía asimétrica que utiliza luego para generar las sesiones SSH. El Fingerprint, es un número que fue calculado con el algortimo ECDSA a partir de la clave pública del servidor. De esta manera si nosostros tenemos otro mecanismo para verficar el fingerprint podremos saber si este es o no el host al que nos queremos conectar.

    Una vez que decimos que queremos continuar, este fingerprint es almacenado en el archivo ~/.ssh/known_hosts, por lo que la verificación para los siguientes casos será automática revisando el archivo.

  3. Una vez que nos pudimos conectar, tenemos acceso a una terminal. De esta manera vamos a verificar con netstat -plunt que el equipo remoto tiene una conexión establecida desde el equipo local (con puerto efímero) al equipo remoto (con puerto 22).

  4. Para crear la sesión segura de comunicación se ha utilizado un algoritmo que permite establecer una contraseña simétrica para cifrar el contenido de toda la conexión. Este algoritmo se conoce con el nombre de “Diffie-Hellman Key Exchange Algorithm” o simplemente Diffie-Hellman. Este algoritmo, de forma somera, funciona de la siguiente manera:

    • Tanto el cliente como el servidor acuerdan un número primo muy grande. Este valor también se conoce como valor semilla.
    • Luego, las dos partes acuerdan utilizar un mecanismo de cifrado común para generar otro conjunto de valores a partir de los valores semilla de una manera específica. Estos algoritmos, también conocidos como generadores de cifrado, realizan grandes operaciones a partir de la semilla. Un ejemplo de tal tipo de algoritmos es AES (Advanced Encryption Standard).
    • Ambas partes generan independientemente otro número primo. Esto se usa como una clave privada secreta para la interacción.
    • Esta clave privada recién generada, con el número compartido y el algoritmo de cifrado (por ejemplo, AES), se usa para calcular una clave pública que se distribuye a la otra computadora.
    • Luego, las ambos interlocutores usan su clave privada personal, la clave pública compartida de la otra máquina y el número primo original para crear una clave compartida final. Esta clave es calculada independientemente por ambas computadoras, pero creará la misma clave de cifrado en ambos lados.
    • Ahora que ambas partes tienen una clave compartida (que ha sido generada en ambos extremos), pueden cifrar simétricamente toda la sesión SSH.

    Escriba exit en la terminal de la sessión SSH. Inicie una captura y vuelva a iniciar la conexión SSH. Analice la captura y asistido por Wireshark observe que partes puede ver del intercambio ¿Algún dato de usuario viaja por la red sin cifrar? Guarde la captura con nombre conexion-ssh.pncap.

  5. Otra utilidad que aprovecha las conexiones seguras SSH es el comando “scp”. Este comando le permite copiar, de forma segura, archivos entre diferentes equipos. Inicie una captura y pruebe enviar un archivo desde una terminal en el host local hacia el host remoto. Para ello ejecute el siguiente comando: scp rutaOrigen
    USER@REMOTO:/rutaDestino     El cliente scp, realizará una conexión SSH y luego enviará los datos del archivo de usuario utilizando esta sesión. Detenga la captura y compárela con la captura conexion-ssh.pncap.

  6. SSH permite además aprovechar las sesiones seguras de comunicación para transportar datos de otras aplicaciones. Esto es lo que se conoce comúnmente con el nombre de “túnel SSH”. Existen muchas formas y alternativas de conexión, incluso uno puede realizar un túnel a través de más de un servidor SSH. Los túneles son una herramienta muy versátil que permite transportar de forma segura protocolos de aplicación así también como eludir ciertas reglas de firewall para poder comunicarnos con servicios no permitidos. Para entender el funcionamiento de esta herramienta seguiremos el siguiente ejemplo, con un túnel de tipo local (-L).

    ssh -L 8000:IP-REMOTO:80 USUARIO@IP-REMOTO

    El resultado de este comando es que cuando nosotros iniciemos un navegador web en el host local y coloquemos allí la dirección: 127.0.0.1:8000 obtendremos como respuesta lo que sea que se esté sirviendo en el puerto 80 de la máquina remota.

    Lo que sucede aquí es que el cliente SSH inicia una conexión segura con el servidor remoto. El cliente local ssh, además, pondrá en escucha un servicio en el puerto local 8000 para su ip 127.0.0.1. Todo tráfico local que esté destinado al puerto 8000 será encapsulado en paquetes SSH y enviados al equipo remoto. Luego en el equipo remoto se tomarán esos paquetes y serán reenviados al puerto 80 de la máquina remota. La respuesta luego realizará el camino inverso.

    Como puede observar toda la conexión se realiza al puerto 22 del equipo remoto y ningún intermediario (y esto incluye a los posibles firewalls) podrá ver que en realidad se está realizando una consulta HTTP al servidor remoto. Ejecute el mencionado comando y verifique que el comportamiento sea el esperado.

Trabajo Práctico

  1. Acceda a https://www2.mincyt.gob.ar/ y tome nota del error. ¿Por qué el navegador dice no confiar en el contenido de esa web? (ayuda: haga clic en “Avanzadas”).
    Repita los pasos para el sitio web https://www.incucai.gov.ar/ e indique también el motivo en este caso. ¿Qué validación no se cumple en este caso?

  2. ¿Cuántas Autoridades de Certificación (CA) son reconocidas por su navegador web? ¿Qué problemas puede ocasionar la adición de nueva autoridad de certificación falsa? ¿Qué problemas puede ocasionar la eliminación de una o más autoridades de la lista?

  3. ¿A que corresponden las extensiones de archivos “.crt”, “.key” y “.csr” en el contexto de los certificados?

  4. ¿Qué modificaciones debe realizar en un servidor web apache2 para proveer servicio de HTTPS? ¿Cómo se agrega, en este contexto, un certificado a un sitio web? ¿Por qué son necesarios tanto el certificado como la clave privada?

  5. ¿En qué situación los certificados que son firmados por un tercero pueden aún considerarse no seguros para un navegador? ¿Cómo se puede lograr que un navegador confíe en el certificado para esta situación?

  6. ¿En qué escenarios pueden resultar útiles los certificados autofirmados?

  7. Analice el archivo cert_servidor_laboratorio ¿Qué información, que considere útil, puede recuperar de allí?

  8. Realice un análisis de la captura cap-ejer-ssl-2024.pcap y donde:

    1. Identifique las distintas etapas del protocolo TLS.
    2. Identifique opciones intercambiadas respecto a Cipher Suite y Extensiones soportadas.
    3. Identifique la información del los certificados y valídela contra lo generado en los pasos previos. Indique si el certificado es válido para el dominio/ip accedido y si aún es vigente.

Guia de lectura

  1. ¿En qué consiste un certificado X.509?
  2. ¿Por qué son necesarias las Autoridades de Certificación (CA)? ¿Cómo distribuyen sus claves públicas a todos los usuarios?
  3. ¿Qué diferencia tecnológica existe entre un certificado autofirmado y un certificado firmado por una CA?
  4. Nombre al menos cuatro causas por las que un certificado HTTPS puede ser inválido.
  5. ¿Cómo establece TLS la conexión segura entre un navegador en el equipo de un cliente y un servidor web que implementa HTTPS?
  6. Los certificados X.509, ¿se utilizan en otro contexto más allá de TLS?
  7. ¿Por qué motivo se utilizan claves simétricas en una conexión TLS?

Anexo

Creación de un certificado autofirmado (sólo para proveer Confidencialidad)

  1. Generar la clave privada (Private Key) del servidor, que será almacenada en el archivo server.key.

     openssl genrsa -out server.key 4096

  2. Generar la solicitud de firma de certificado (Certificate Signing Request), que será almacenada en el archivo server.csr. Completar los campos solicitados según el formulario de solicitud. Por ejemplo:

     openssl req -new -sha256 -key server.key -out server.csr
 -----
 Country Name (2 letter code): AR
 State or Province Name (full name): Buenos Aires
 Locality Name (eg, city): Lujan
 Organization Name (eg, company): Organización Example S.A.
 Organizational Unit Name (eg, section): Gerencia de Sistemas
 Common Name (eg, YOUR name): SU-DIRECCION-IP
 Email Address: SU-DIRECCION-DE-CORREO

 Please enter the following 'extra' attributes to be sent with your cert req.
 A challenge password:
 An optional company name:

  3. Firmar la petición con la propia clave privada como sigue. En este caso se lo denomina “auto-firmar”, puesto que estamos firmando la clave pública con la misma clave privada que le corresponde. En los sitios web que operan con TLS, quien firma la petición es una tercera entidad (una Autoridad de Certificación) en la que “todos” confían.

     openssl x509 -req -days 365 -sha256 -in server.csr -signkey server.key 
              -out server.crt

  4. Para visualizar el contenido del certificado digital, ejecutar:

     openssl x509 -text -in server.crt

Pasos a seguir para configurar e instalar los certificados en el servidor web

  1. Instalar el servidor web Apache 2 o superior.

     # apt-get install apache2

  2. Activar los módulos rewrite y ssl, y el sitio default-ssl en Apache.

     # a2enmod rewrite
 # a2enmod ssl
 # a2ensite default-ssl

  3. Crear la ubicación /etc/apache2/certificados donde se almacenarán los certificados, copiarlos a la misma y asignar los permisos adecuados según la documentación disponible en /usr/share/doc/apache2/README.Debian.gz:

     #
 # mkdir /etc/apache2/certificados
 # cd /etc/apache2/certificados
 # mv origen/server.crt .
 # mv origen/server.key .
 # chown root.root server.crt server.key
 # chmod 444 server.crt
 # chmod 400 server.key

  4. Editar el archivo /etc/apache2/sites-enabled/default-ssl.conf y reemplazar las líneas SSLCertificateFile y SSLCertificateKeyFile según sigue:

     SSLCertificateFile  /etc/apache2/certificados/server.crt
 SSLCertificateKeyFile   /etc/apache2/certificados/server.key

  5. De ser necesario, habilitar el acceso al puerto 443 en el firewall del host y los nodos que correspondan.

  6. Reiniciar el servidor apache (no alcanza sólo con recargar la configuración).

     # service apache2 restart