Configure SSL/TLS en Amazon Linux - Amazon Elastic Compute Cloud
Requisitos previosPaso 1: Habilitar TLS en el servidorPaso 2: Obtener un certificado firmado por una CAPaso 3: Probar y reforzar la configuración de seguridadSolución de problemas

Configure SSL/TLS en Amazon Linux

SSL/TLS (Secure Sockets Layer/Transport Layer Security) crea un canal cifrado entre un servidor web y el cliente web que protege los datos en tránsito del acceso no autorizado. En este tutorial, se explica cómo añadir soporte manualmente para SSL/TLS en una instancia EC2 con la AMI de Amazon Linux y el servidor web de Apache. En este tutorial, se presupone que no está utilizando un balanceador de carga. Si utiliza Elastic Load Balancing, puede elegir configurar la descarga SSL en el balanceador de carga, mediante un certificado de AWS Certificate Manager en su lugar.

Por motivos históricos, el cifrado web se suele denominar simplemente SSL. Aunque los navegadores web siguen admitiendo SSL, el protocolo que lo ha sustituido, TLS, es menos vulnerable a los ataques. La AMI de Amazon Linux deshabilita el soporte del lado del servidor de todas las versiones de SSL de manera predeterminada. Organismos de estándares de seguridad consideran que TLS 1.0 no es seguro. TLS 1.0 y TLS 1.1 han quedado formalmente obsoletos en marzo de 2021. Este tutorial contiene asesoramiento basado exclusivamente en la habilitación de TLS 1.2. TLS 1.3 se finalizó en 2018 y está disponible en Amazon Linux 2 siempre que la biblioteca TLS subyacente (OpenSSL en este tutorial) sea compatible y esté habilitada. Los clientes deben ser compatibles con TLS 1.2 o una versión posterior antes del 28 de junio de 2023. Para obtener más información sobre el estándar de cifrado actualizado, consulte RFC 7568 y RFC 8446.

Este tutorial se refiere a un cifrado web moderno tan simple como TLS.

importante

Estos procedimientos son para usar con la AMI de Amazon Linux. Si está intentando configurar un servidor web LAMP en una instancia con otra distribución, algunos procedimientos de este tutorial puede que no sean adecuados. Para Amazon Linux 2, consulte Configurar SSL/TLS en Amazon Linux 2. Para Ubuntu, consulte la siguiente documentación de la comunidad: Open SSL on Ubuntu (Abrir SSL en Ubuntu). Para Red Hat Enterprise Linux, consulte lo siguiente: Configuración del servidor web HTTP Apache. Para otras distribuciones, consulte su documentación específica.

nota

También puede utilizar AWS Certificate Manager (ACM) para Nitro Enclaves de AWS, que es una aplicación de enclave que le permite utilizar certificados SSL/TLS públicos y privados con sus aplicaciones y servidores web que se ejecutan en instancias de Amazon EC2 con Nitro Enclaves de AWS. Nitro Enclaves es una capacidad de Amazon EC2 que permite la creación de entornos informáticos aislados para proteger y procesar de forma segura información confidencial, como certificados SSL/TLS y claves privadas.

ACM para Nitro Enclaves funciona con nginx ejecutándose en su instancia de Amazon EC2 Linux para crear claves privadas, distribuir certificados y claves privadas y para administrar las renovaciones de certificados.

Para utilizar ACM para Nitro Enclaves, debe utilizar una instancia Linux habilitada para enclave.

Para obtener más información, consulte ¿Qué es AWS Nitro Enclaves? y AWS Certificate Manager para Nitro Enclaves en la AWS Guía del usuario de Nitro Enclaves.

Requisitos previos

Siga estos pasos antes de comenzar este tutorial:

  • Lance una instancia con respaldo de EBS utilizando la AMI de Amazon Linux. Para obtener más información, consulte Paso 1: Lanzamiento de una instancia.

  • Configure el grupo de seguridad para que la instancia acepte conexiones en los siguientes puertos TCP:

    • SSH (puerto 22)

    • HTTP (puerto 80)

    • HTTPS (puerto 443)

    Para obtener más información, consulte Autorizar tráfico entrante para las instancias de Linux.

  • Instale un servidor web Apache. Para leer las instrucciones detalladas, consulte Tutorial: Instalación de un servidor web LAMP en Amazon Linux. Solo es necesario el paquete http24 y sus dependencias; puede omitir las instrucciones relacionadas con PHP y MySQL.

  • Para identificar y autenticar sitios web, la infraestructura de clave pública (PKI) de TLS se basa en el sistema de nombres de dominio (DNS). Si tiene pensado utilizar la instancia EC2 para alojar un sitio web público, tiene que registrar un nombre de dominio para el servidor web o transferir un nombre de dominio existente al host de Amazon EC2. Para hacer esto, hay disponibles numerosos servicios de registro de dominios y alojamiento de DNS de terceros o bien puede utilizar Amazon Route 53.

Paso 1: Habilitar TLS en el servidor

Opción: completar este tutorial con la automatización

Para completar este tutorial con AWS Systems Manager en lugar de las siguientes tareas, ejecute el documento de automatización.

Este procedimiento le guía a lo largo del proceso de configuración de TLS en Amazon Linux con un certificado digital autofirmado.

nota

Se puede utilizar un certificado autofirmado para las pruebas, pero no para la producción. Si expone a Internet su certificado autofirmado, los visitantes del sitio reciben advertencias de seguridad.

Para habilitar TLS en un servidor

  1. Conéctese a su instancia y confirme que Apache se está ejecutando.

    [ec2-user ~]$ sudo service httpd status

    Si es necesario, inicie Apache.

    [ec2-user ~]$ sudo service httpd start

  2. Para asegurarse de que todos los paquetes de software están actualizados, realice una actualización rápida del software en la instancia. Este proceso puede durar unos minutos, pero es importante realizarlo para asegurarse de que tiene las actualizaciones de seguridad y soluciones de errores más recientes.

    nota

    La opción -y instala las actualizaciones sin necesidad de confirmación. Si le gustaría examinar las actualizaciones antes de la instalación, puede omitir esta opción.

    [ec2-user ~]$ sudo yum update -y

  3. Ahora que la instancia está actualizada y admite TLS instalando el módulo de Apache mod_ssl:

    [ec2-user ~]$ sudo yum install -y mod_ssl

    La instancia tiene ahora los archivos siguientes que utiliza para configurar el servidor seguro y crear un certificado para pruebas:

    /etc/httpd/conf.d/ssl.conf

    El archivo de configuración para mod_ssl. Contiene “directivas” que le indican a Apache donde encontrar claves de cifrado y certificados, las versiones de protocolo TLS que se permiten y los cifrados que se aceptan.

    /etc/pki/tls/private/localhost.key

    Una clave privada RSA de 2048 bits generada automáticamente para el host de Amazon EC2. Durante la instalación, OpenSSL utilizó esta clave para generar un certificado de host autofirmado. También puede utilizar esta clave para generar una solicitud de firma de certificado (CSR) para enviársela a una entidad de certificación (CA).

    /etc/pki/tls/certs/localhost.crt

    Un certificado X.509 autofirmado generado automáticamente para el host del servidor. Este certificado es útil para probar si Apache está configurado correctamente para utilizar TLS.

    Los archivos .key y .crt están en formato PEM, que consta de caracteres ASCII codificados en Base64 contenidos entre las líneas "BEGIN" y "END", como en este ejemplo abreviado de un certificado:

    -----BEGIN CERTIFICATE-----
MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
...
z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
-----END CERTIFICATE-----

    Los nombres y las extensiones de los archivos se utilizan simplemente por comodidad y no afectan al funcionamiento; puede llamar a un certificado cert.crt, cert.pem o de cualquier otra forma, siempre y cuando la directiva relacionada del archivo ssl.conf utilice el mismo nombre.

    nota

    Cuando sustituya los archivos TLS predeterminados por sus propios archivos personalizados, asegúrese de que estén en formato PEM.

  4. Reinicie Apache.

    [ec2-user ~]$ sudo service httpd restart

  5. Ahora el servidor web de Apache debería admitir HTTPS (HTTP seguro) en el puerto 443. Para probarlo, escriba la dirección IP o el nombre completo de dominio de la instancia EC2 en la barra URL del navegador con el prefijo https://. Dado que se va a conectar a un sitio con un certificado de host autofirmado que no es de confianza, es posible que el navegador envíe una serie de advertencias de seguridad.

    Omita las advertencias y vaya al sitio. Si se abre la página de prueba de Apache predeterminada, eso significa que ha configurado correctamente TLS en el servidor. Ahora todos los datos que pasan entre el navegador y el servidor se cifran con seguridad.

    Para evitar que los visitantes del sitio reciban pantallas de advertencia, tiene que obtener un certificado que no solo cifre, sino que también le autentique públicamente como propietario del sitio.

Paso 2: Obtener un certificado firmado por una CA

Puede utilizar el siguiente proceso para obtener un certificado firmado por una CA:

  • Genere una solicitud de firma de certificado (CSR) de una clave privada

  • Envie el CSR a una autoridad de certificación (CA)

  • Obtenga un certificado de host firmado

  • Configure Apache para utilizar el certificado

Un certificado de host TLS X.509 autofirmado es idéntico, desde el punto de vista criptográfico, a un certificado firmado por una CA. La diferencia es social, no matemática; una CA promete validar, como mínimo, la propiedad de un dominio antes de emitir un certificado para el solicitante. Para ello, cada navegador web contiene una lista de CA de confianza del proveedor del navegador. Un certificado X.509 consta principalmente de una clave pública, que se corresponde con la clave del servidor privado, y una firma de la CA que está vinculada criptográficamente a la clave pública. Cuando un navegador se conecta a un servidor web a través de HTTPS, el servidor presenta un certificado al navegador para que lo compruebe en su lista de CA de confianza. Si el signatario está en la lista o se puede obtener acceso a él a través de una cadena de confianza compuesta por otros signatarios de confianza, el navegador negocia un canal de datos cifrados rápido con el servidor y carga la página.

Generalmente, los certificados cuestan dinero por el trabajo que supone la validación de las solicitudes, por lo que vale la pena comparar precios. Hay varias CA que ofrecen certificados básicos de manera gratuita. La más famosa de estas CA es la del proyecto Let's Encrypt, que también permite la automatización del proceso de creación y renovación del certificado. Para obtener más información acerca del uso del certificado Let's Encrypt, consulte Obtenga Certbot.

Si planea ofrecer servicios de calidad comercial, AWS Certificate Manager es una buena opción.

La clave es hacer que el certificado del host esté subyacente. Desde 2017, grupos del gobierno y el sector recomiendan utilizar un tamaño mínimo de clave (módulo) de 2048 bits para claves RSA destinadas a proteger documentos hasta 2030. El tamaño de módulo predeterminado que genera OpenSSL en Amazon Linux es 2048 bits, lo que significa que la clave autogenerada existente se puede utilizar en un certificado firmado por una CA. A continuación, se describe un procedimiento alternativo para quienes deseen una clave personalizada; por ejemplo, con un módulo mayor o que utilice un algoritmo de cifrado diferente.

Estas instrucciones para adquirir un certificado de host firmado por una CA no funcionan a menos que posea un dominio DNS alojado y registrado.

Para obtener un certificado firmado por una CA

  1. Conéctese a la instancia y vaya a /etc/pki/tls/private/. Este es el directorio en el que se almacena la clave privada del servidor para TLS. Si prefiere utilizar su clave de host existente para generar el CSR, vaya al paso 3.

  2. (Opcional) Genere una nueva clave privada. Estas son algunas ejemplos de configuraciones clave. Cualquiera de las claves resultantes funciona con el servidor web, pero son diferentes en cómo (y cuánto) implementan la seguridad.

    • Ejemplo 1: cree una clave de host RSA predeterminada. El archivo resultante, custom.key, es una clave privada RSA de 2048 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key

    • Ejemplo 2: cree una clave RSA más segura con un módulo mayor. El archivo resultante, custom.key, es una clave privada RSA de 4096 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096

    • Ejemplo 3: cree una clave RSA cifrada de 4096 bits con protección con contraseña. El archivo resultante, custom.key, es una clave privada RSA de 4096 bits cifrada con AES-128.

      importante

      El cifrado de la clave ofrece mayor seguridad, pero dado que una clave cifrada necesita una contraseña, los servicios que dependen de él no se pueden iniciar automáticamente. Cada vez que utilice esta clave, tiene que proporcionar la contraseña (en el ejemplo anterior "abcde12345") en una conexión SSH.

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096

    • Ejemplo 4: cree una clave con un cifrado que no sea RSA. La criptogarfía RSA puede ser relativamente lenta debido al tamaño de sus claves públicas, que se basan en el producto de dos números primos grandes. Sin embargo, es posible crear claves para TLS que utilicen cifrados que no sean RSA. Las claves que están basadas en el cálculo matemático de curvas elípticas son más pequeñas y más rápidas desde el punto de vista informático a la hora de proporcionar un nivel de seguridad equivalente.

      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      El resultado es una clave privada de curva elíptica de 256 bits que utiliza prime256v1, una "curva con nombre" que admite OpenSSL. Su seguridad criptográfica es ligeramente mayor que la de una clave RSA de 2048 bits, de acuerdo con NIST.

      nota

      No todas las CA ofrecen el mismo nivel de soporte de claves basadas en curvas elípticas que de claves RSA.

    Asegúrese de que la nueva clave privada posee una propiedad y unos permisos muy restrictivos (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario). Los comandos serían los siguientes:

    [ec2-user ~]$ sudo chown root.root custom.key
[ec2-user ~]$ sudo chmod 600 custom.key
[ec2-user ~]$ ls -al custom.key

    Los comandos anteriores deberían devolver el siguiente resultado:

    -rw------- root root custom.key

    Una vez que haya creado y configurado una clave satisfactoria, puede crear una CSR.

  3. Cree una CSR con su clave preferida. El siguiente ejemplo utiliza custom.key:

    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    OpenSSL abre un cuadro de diálogo y le pide la información que se muestra en la siguiente tabla. Todos los campos, excepto Common Name (Nombre común), son opcionales para un certificado de host de dominio validado básico.

    Nombre Descripción Ejemplo
    Country Name La abreviatura ISO de dos letras del país. US (= Estados Unidos)
    State or Province Name Nombre del país o de la región donde se ubica su organización. Este nombre no se puede abreviar. Washington
    Locality Name La ubicación de su organización, como una ciudad. Seattle
    Organization Name Nombre legal completo de su organización. No abrevie el nombre de la organización. Empresa de ejemplo
    Organizational Unit Name Información adicional de la organización, si existe. Departamento de ejemplo
    Common Name

    Este valor debe ser exactamente igual que la dirección web que espera que escriban los usuarios en un navegador. Normalmente, tiene que ser un nombre de dominio precedido por un nombre de host o alias con el formato www.example.com. Para realizar pruebas con un certificado autofirmado y sin resolución de DNS, el nombre común puede constar únicamente del nombre de host. Las CA también disponen de certificados más caros que aceptan nombres con comodines, como *.example.com.

    		 www.ejemplo.com
    Email Address Dirección de correo electrónico del administrador del servidor. alguien@ejemplo.com

    Por último, OpenSSL le solicita una contraseña de comprobación opcional. Esta contraseña solo se aplica a la CSR y a las transacciones entre usted y la CA, así que siga las recomendaciones de la CA a este respecto y el otro campo opcional, es decir, el nombre de empresa opcional. La contraseña de comprobación de CSR no afecta al funcionamiento del servidor.

    El archivo resultante, csr.pem contiene la clave pública, la firma digital de la clave pública y los metadatos que ha especificado.

  4. Envíe la CSR a una CA. Este proceso suele consistir en abrir el archivo CSR en un editor de texto y copiar el contenido en un formulario web. Es posible que, en este momento, se le solicite que introduzca uno o varios nombres de asunto alternativos (SAN) para que aparezcan en el certificado. Si el nombre común es www.example.com, example.com sería un buen SAN y viceversa. Un visitante de su sitio que escribiera cualquiera de estos nombres no recibiría ningún error de conexión. Si el formato web de la CA lo permite, incluya el nombre común en la lista de SAN. Algunas CA lo incluyen automáticamente.

    Una vez aprobada su solicitud, recibe un nuevo certificado de host firmado por la CA. Es posible que también tenga que descargar un archivo de certificado intermedio que contiene los certificados adicionales necesarios para completar la cadena de confianza de la CA.

    nota

    La CA puede enviarle archivos en diversos formatos destinados a diversos fines. Para este tutorial, solo debe utilizar un archivo de certificado en formato PEM, que normalmente (aunque no siempre) está marcado con la extensión .pem o .crt. Si no tiene claro qué archivo debe utilizar, abra los archivos con un editor de texto y busque el que contiene uno o varios bloques que comienzan con lo siguiente:

    - - - - -BEGIN CERTIFICATE - - - - -

    El archivo debería terminar también de la siguiente manera:

    - - - -END CERTIFICATE - - - - -

    También puede probar un archivo en la línea de comandos, tal y como se indica a continuación:

    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    Verifique que estas líneas aparecen en el archivo. No utilice archivos que terminen con .p7b, .p7c o extensiones de archivos similares.

  5. Coloque el nuevo certificado firmado por la CA y cualquier certificado intermedio en el directorio /etc/pki/tls/certs.

    nota

    Hay varias formas de cargar la clave personalizada en la instancia EC2, pero la más sencilla e informativa consiste en abrir un editor de texto (por ejemplo, vi, nano o notepad) en el equipo local y en la instancia y, a continuación, copiar y pegar el contenido del archivo de uno al otro. Para realizar estas operaciones en la instancia EC2, necesita permisos de raíz [sudo]. De esta forma, puede ver inmediatamente si hay algún problema con los permisos o las rutas. Procure, no obstante, no añadir más líneas al copiar el contenido o cambiarlo de ninguna forma.

    Utilice, desde el interior del directorio /etc/pki/tls/certs, los siguientes comandos para verificar que la propiedad del archivo, grupo y permisos se corresponden con los ajustes predeterminados enormemente restrictivos de Amazon Linux (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario).

    [ec2-user certs]$ sudo chown root.root custom.crt
[ec2-user certs]$ sudo chmod 600 custom.crt
[ec2-user certs]$ ls -al custom.crt

    Los comandos anteriores deberían devolver el siguiente resultado: 

    -rw------- root root custom.crt

    Los permisos del archivo de certificado intermedio son menos estrictos (propietario=raíz, grupo=raíz, propietario puede escribir, grupo puede leer, mundo puede leer). Los comandos serían los siguientes: 

    [ec2-user certs]$ sudo chown root.root intermediate.crt
[ec2-user certs]$ sudo chmod 644 intermediate.crt
[ec2-user certs]$ ls -al intermediate.crt

    Los comandos anteriores deberían devolver el siguiente resultado:

    -rw-r--r-- root root intermediate.crt

  6. Si ha utilizado una clave personalizada para crear la CSR y el certificado de host resultante, elimine o cambie el nombre de la clave antigua del directorio /etc/pki/tls/private/ y luego instale allí la nueva clave.

    nota

    Hay varias formas de cargar la clave personalizada en la instancia EC2, pero la más sencilla e informativa consiste en abrir un editor de texto (vi, nano, notepad, etc.) en el equipo local y en la instancia y, a continuación, copiar y pegar el contenido del archivo de uno al otro. Para realizar estas operaciones en la instancia EC2, necesita privilegios de raíz [sudo]. De esta forma, puede ver inmediatamente si hay algún problema con los permisos o las rutas. Procure, no obstante, no añadir más líneas al copiar el contenido o cambiarlo de ninguna forma.

    Compruebe, desde el interior del directorio /etc/pki/tls/private, que los ajustes de propiedad del archivo, grupo y permisos se corresponden con los ajustes predeterminados enormemente restrictivos de Amazon Linux (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario). Los comandos serían los siguientes: 

    [ec2-user private]$ sudo chown root.root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ ls -al custom.key

    Los comandos anteriores deberían devolver el siguiente resultado: 

    -rw------- root root custom.key

  7. Edite /etc/httpd/conf.d/ssl.conf para reflejar el nuevo certificado y los archivos de claves.

    1. Proporcione la ruta y el nombre de archivo del certificado de host firmado por la CA en la directiva SSLCertificateFile de Apache:

      SSLCertificateFile /etc/pki/tls/certs/custom.crt

    2. Si ha recibido un archivo de certificado intermedio (intermediate.crt en este ejemplo), proporcione su ruta y nombre de archivo utilizando la directiva SSLCACertificateFile de Apache:

      SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
      nota

      Algunas CA combinan el certificado de host y los certificados intermedios en un solo archivo, por lo que, en ese caso, esta directiva es innecesaria. Consulte las instrucciones que le ha proporcionado su CA.

    3. Proporcione la ruta y el nombre de archivo de la clave privada en la directiva SSLCertificateKeyFile de Apache:

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key

  8. Guarde /etc/httpd/conf.d/ssl.conf y reinicie Apache.

    [ec2-user ~]$ sudo service httpd restart

  9. Pruebe el servidor introduciendo su nombre de dominio en una barra de direcciones URL del navegador con el prefijo https://. El navegador debería cargar la página de prueba sobre HTTPS sin generar errores.

Paso 3: Probar y reforzar la configuración de seguridad

Cuando su TLS esté en funcionamiento y expuesto al público, debería probar su seguridad. Esta operación es muy sencilla con servicios online como Qualys SSL Labs, que realiza un análisis gratuito y exhaustivo de su configuración de seguridad. En función de los resultados, puede decidir si debe reforzar la configuración de seguridad predeterminada controlando los protocolos que acepta, qué cifrados prefiere y cuáles deben excluirse. Para obtener más información, consulte cómo Qualys formula sus puntuaciones.

importante

Las pruebas reales son cruciales para la seguridad del servidor. Cualquier pequeño error de configuración puede provocar graves infracciones de seguridad y la pérdida de datos. Dado que las prácticas de seguridad recomendadas cambian continuamente en respuesta a las investigaciones y a las continuas amenazas, es esencial realizar auditorías de seguridad periódicas para mantener una buena administración del servidor.

En el sitio de Qualys SSL Labs, escriba el nombre de dominio completo de su servidor, con el formato www.example.com. Dos minutos después recibirá una puntuación (de A a F) de su sitio y un desglose detallado de los descubrimientos. Aunque la información general muestra que la configuración es correcta, el informe detallado indica algunos posibles problemas. Por ejemplo:

✗ Algunos navegadores más antiguos admiten el uso del cifrado RC4. Un cifrado es el núcleo matemático de un algoritmo de cifrado. Se sabe que RC4, un cifrado rápido que sirve para cifrar flujos de datos TLS, tiene varios puntos débiles importantes. A menos que tenga muy buenas razones para admitir navegadores heredados, debería deshabilitar esta opción.

✗ Se admiten las versiones antiguas de TLS. La configuración admite TLS 1.0 (ya obsoleto) y TLS 1.1 (en vías de ser declarado obsoleto). Desde 2018 solo se ha recomendado TLS 1.2.

Para corregir la configuración de TLS

  1. Abra el archivo de configuración /etc/httpd/conf.d/ssl.conf en un editor de texto y comente las líneas siguientes escribiendo "#" al principio de cada una:

    #SSLProtocol all -SSLv3
#SSLProxyProtocol all -SSLv3

  2. Añada las siguientes directivas:

    SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Estas directivas deshabilitan explícitamente las versiones 2 y 3 de SSL, además de las versiones 1.0 y 1.1 de TLS. Ahora, el servidor se niega a aceptar conexiones cifradas con clientes que no utilicen versiones compatibles de TLS 1.2. El texto de la directiva comunica con más claridad a un lector humano las acciones que se han configurado que haga el servidor.

    nota

    Al deshabilitar las versiones 1.0 y 1.1 de TLS de esta manera, bloquea un pequeño porcentaje de navegadores web desactualizados y evita que obtengan acceso a su sitio.

Para modificar la lista de cifrados permitidos

  1. En el archivo de configuración /etc/httpd/conf.d/ssl.conf, busque la sección que contiene ejemplos comentados para configurar SSLCipherSuite y SSLProxyCipherSuite.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
#SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

    Déjelos como está y, debajo, añada las siguientes directivas:

    nota

    Aunque aquí se muestran en varias líneas para que la lectura sea más sencilla, cada una de estas dos directivas debe estar en una sola línea sin espacios entre los nombres de los cifrados.

    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLProxyCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

    Estos cifrados son un subconjunto de una lista mucho más larga de cifrados admitidos en OpenSSL. Se han seleccionado y ordenado de acuerdo con los siguientes criterios:

    • Soporte de confidencialidad directa

    • Nivel de seguridad

    • Velocidad

    • Cifrados específicos antes de familias de cifrados

    • Cifrados permitidos antes de cifrados denegados

    Tenga en cuenta que los cifrados con la calificación más alta tienen ECDHE en su nombre; por ejemplo, en Elliptic Curve Diffie-Hellman Ephemeral, ephemeral indica la confidencialidad directa. Además, RC4 ahora se encuentra entre los cifrados prohibidos casi al final.

    Le recomendamos utilizar una lista de cifrados explícita en lugar de utilizar valores predeterminados o directivas escuetas cuyo contenido no es visible. La lista de cifrados que se muestra aquí es una de las muchas listas posibles; por ejemplo, podría querer optimizar una lista para la velocidad, en lugar de la confidencialidad directa.

    Si prevé que será necesario dar soporte a clientes más antiguos, puede permitir la suite de cifrados DES-CBC3-SHA.

    Por último, en cada actualización de OpenSSL, se introducen nuevos cifrados y se dan de baja los antiguos. Mantenga actualizada la instancia EC2 de Amazon Linux, esté pendiente de las novedades sobre seguridad de OpenSSL y permanezca al corriente de los informes sobre nuevas vulnerabilidades de seguridad que se publican en la prensa técnica.

  2. Cancele el comentario de la siguiente línea eliminando el "#":

    #SSLHonorCipherOrder on

    Este comando obliga al servidor a preferir cifrados con una calificación alta, incluidos (en este caso) los que admiten la confidencialidad directa. Con esta directiva activada, el servidor intenta establecer una conexión muy segura antes de recurrir a los cifrados permitidos con menor seguridad.

  3. Reinicie Apache. Si vuelve a probar el dominio en Qualys SSL Labs, debería ver que la vulnerabilidad de RC4 ha desaparecido.

Solución de problemas

  • Mi servidor web Apache no se inicia a menos que especifique una contraseña

    Es el comportamiento esperado si ha instalado una clave de servidor privado cifrada y protegida mediante contraseña.

    Puede eliminar el cifrado y el requisito de contraseña de la clave. Supongamos que tiene una clave RSA cifrada privada que se denomina custom.key en el directorio predeterminado y que su contraseña es abcde12345. Ejecute los siguientes comandos en la instancia EC2 para generar una versión no cifrada de la clave.

    [ec2-user ~]$ cd /etc/pki/tls/private/
[ec2-user private]$ sudo cp custom.key custom.key.bak
[ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt 
[ec2-user private]$ sudo mv custom.key.nocrypt custom.key
[ec2-user private]$ sudo chown root.root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ sudo service httpd restart

    Ahora, Apache debería iniciarse sin solicitarle una contraseña.