Tutorial: ConfigurarSSL/TLSem AL2 023 - Amazon Linux 2023

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Tutorial: ConfigurarSSL/TLSem AL2 023

Soquetes seguros Layer/Transport Layer Security (SSL/TLS) creates an encrypted channel between a web server and web client that protects data in transit from being eavesdropped on. This tutorial explains how to add support manually for SSL/TLS em uma EC2 instância com AL2 023 e servidor web Apache. Este tutorial pressupõe que você não esteja usando um balanceador de carga. Se você estiver usando o Elastic SSL Load Balancing, poderá optar por configurar o descarregamento no balanceador de carga, usando um certificado do. AWS Certificate Manager

Por razões históricas, a criptografia da web geralmente é chamada simplesmente deSSL. Embora os navegadores da Web ainda suportemSSL, seu protocolo sucessor TLS é menos vulnerável a ataques. AL2023 desativa o suporte do lado do servidor para todas as versões do, por padrão. SSL Os órgãos de padrões de segurança consideram que TLS 1.0 não é seguro. TLS1.0 e TLS 1.1 foram formalmente descontinuados em março de 2021. Este tutorial contém orientações baseadas exclusivamente na ativação da versão TLS 1.2. TLSA versão 1.3 foi finalizada em 2018 e está disponível AL2 desde que a TLS biblioteca subjacente (aberta SSL neste tutorial) seja suportada e habilitada. Os clientes devem oferecer suporte à versão TLS 1.2 ou posterior até 28 de junho de 2023. Para obter mais informações sobre os padrões de criptografia atualizados, consulte RFC7568 e RFC8446.

Este tutorial se refere à criptografia da web moderna simplesmente comoTLS.

Importante

Esses procedimentos são destinados ao uso com AL2 023. Se você estiver tentando configurar uma EC2 instância executando uma distribuição diferente ou uma instância executando uma versão antiga do Amazon Linux, alguns procedimentos deste tutorial podem não funcionar. Para o Ubuntu, consulte a seguinte documentação da comunidade Ubuntu: Abrir SSL no Ubuntu. Para o Red Hat Enterprise Linux, consulte o seguinte: Configurando o Apache HTTP Web Server. Para outras distribuições, consulte a documentação específica.

nota

Como alternativa, você pode usar AWS Certificate Manager (ACM) para enclaves AWS Nitro, que é um aplicativo de enclave que permite usar TLS certificadosSSL/públicos e privados com seus aplicativos e servidores web em execução em EC2 instâncias da Amazon com o Nitro Enclaves. AWS O Nitro Enclaves é um EC2 recurso da Amazon que permite a criação de ambientes computacionais isolados para proteger e processar com segurança dados altamente confidenciais, como SSL /certificados e chaves privadas. TLS

ACMfor Nitro Enclaves funciona com o nginx em execução na sua instância EC2 Amazon Linux para criar chaves privadas, distribuir certificados e chaves privadas e gerenciar renovações de certificados.

ACMPara usar o Nitro Enclaves, você deve usar uma instância Linux habilitada para enclave.

Para obter mais informações, consulte O que são AWS Nitro Enclaves? e AWS Certificate Manager para Nitro Enclaves no Guia do usuário do AWS Nitro Enclaves.

Pré-requisitos

Antes de começar este tutorial, conclua as seguintes etapas:

  • Execute uma instância AL2 023 EBS com suporte eletrônico. Para obter mais informações, consulte AL2023 na Amazon EC2.

  • Configure seus grupos de segurança para permitir que sua instância aceite conexões nas seguintes TCP portas:

    • SSH(porta 22)

    • HTTP(porta 80)

    • HTTPS(porta 443)

    Para obter mais informações, consulte Autorizar tráfego de entrada para suas instâncias Linux no Guia EC2 do usuário da Amazon.

  • Instale o servidor Web Apache. Para step-by-step obter instruções, consulteTutorial: instalar um LAMP servidor em AL2 023. Somente o pacote httpd e suas dependências são necessários, então você pode ignorar as instruções que envolvem o PHP MariaDB.

  • Para identificar e autenticar sites, a infraestrutura de chave TLS pública (PKI) depende do Sistema de Nomes de Domínio (DNS). Para usar sua EC2 instância para hospedar um site público, você precisa registrar um nome de domínio para seu servidor web ou transferir um nome de domínio existente para seu EC2 host da Amazon. Vários serviços de registro e DNS hospedagem de domínios de terceiros estão disponíveis para isso, ou você pode usar o Amazon Route 53.

Etapa 1: habilitar TLS no servidor

Esse procedimento conduz você pelo processo de configuração do TLS AL2 023 com um certificado digital autoassinado.

nota

Um certificado autoassinado é aceitável para testes, mas não para produção. Quando você expõe seu certificado autoassinado na Internet, os visitantes de seu site recebem avisos de segurança.

Para habilitar TLS em um servidor
  1. Conecte-se à sua instância e confirme se o Apache está em execução. Para obter mais informações, consulte Conexão com AL2 203 instâncias.

    [ec2-user ~]$ sudo systemctl is-enabled httpd

    Se o valor retornado não for "habilitado", inicie o Apache e configure-o para iniciar sempre que o sistema for inicializado.

    [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd
  2. Para garantir que todos os pacotes de software estejam atualizados, execute uma atualização rápida de software em sua instância. Esse processo pode levar alguns minutos, mas é importante ter certeza de que você tem as atualizações de segurança e correções de bug mais recentes.

    nota

    A opção -y instala as atualizações sem solicitar confirmação. Para examinar as atualizações antes da instalação, você pode omitir essa opção.

    [ec2-user ~]$ sudo dnf install openssl mod_ssl
  3. Depois de inserir o seguinte comando, você será levado a um prompt onde poderá inserir informações sobre seu site.

    [ec2-user ~]$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/apache-selfsigned.key -out /etc/pki/tls/certs/apache-selfsigned.crt

    Isso gera um novo arquivo apache-selfsigned.crt no diretório /etc/pki/tls/certs/. O nome do arquivo especificado corresponde ao padrão atribuído na diretiva SSLCertificateFile em /etc/httpd/conf.d/ssl.conf.

    Sua instância agora possui os seguintes arquivos que você usará para configurar seu servidor seguro e criar um certificado para teste:

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

      O arquivo de configuração para mod_ssl. Ele contém diretivas que informam ao Apache onde encontrar chaves e certificados de criptografia, as versões do TLS protocolo a serem permitidas e as cifras de criptografia a serem aceitas. Este será o seu arquivo de certificado local:

    • /etc/pki/tls/certs/apache-selfsigned.crt

    Esse arquivo contém um certificado autoassinado e a chave privada do certificado. O Apache exige que o certificado e a chave estejam no PEM formato, que consiste em ASCII caracteres codificados em Base64 emoldurados pelas linhas "" e "BEGIN", como no END exemplo abreviado a seguir.

    -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----

    Os nomes de arquivos e as extensões são uma conveniência e não têm efeito na função. Por exemplo, você pode chamar um certificado de cert.crt, cert.pem ou de um outro nome de arquivo qualquer, desde que a diretiva relacionada no arquivo ssl.conf use o mesmo nome.

    nota

    Ao substituir os TLS arquivos padrão por seus próprios arquivos personalizados, verifique se eles estão no PEM formato.

  4. Reinicie o Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
    nota

    Certifique-se de que a TCP porta 443 esteja acessível na sua EC2 instância, conforme descrito anteriormente.

  5. Seu servidor web Apache agora deve suportar HTTPS (seguroHTTP) a porta 443. Teste inserindo o endereço IP ou o nome de domínio totalmente qualificado da sua EC2 instância em uma URL barra do navegador com o prefixohttps://.

    Como você está se conectando a um site com um certificado de host autoassinado não confiável, o navegador poderá exibir uma série de avisos de segurança. Ignore os avisos e continue para o site.

    Se a página de teste padrão do Apache for aberta, isso significa que você configurou com sucesso TLS em seu servidor. Todos os dados que passam entre o navegador e o servidor agora estão criptografados.

    nota

    Para impedir que os visitantes do site encontrem telas de avisos, você precisa obter um certificado assinado por uma CA confiável que, além de criptografar, também autentique você publicamente como o proprietário do site.

Etapa 2: obter um certificado assinado por uma CA

Você pode seguir este processo para obter um certificado assinado por uma CA:

  • Gere uma solicitação de assinatura de certificado (CSR) a partir de uma chave privada

  • Envie o CSR para uma autoridade de certificação (CA)

  • Obtenha um certificado de host assinado

  • Configure o Apache para usá-lo

Um certificado de host TLS X.509 autoassinado é criptologicamente idêntico a um certificado assinado pela CA. A diferença é social, não matemática. Uma CA promete validar, no mínimo, a propriedade de um domínio antes de emitir um certificado para um candidato. Cada navegador da Web contém uma lista de CAs informações confiáveis do fornecedor do navegador para fazer isso. Primariamente, um certificado X.509 consiste em uma chave pública, que corresponde à chave privada do servidor, e uma assinatura pela CA que é vinculada criptograficamente à chave pública. Quando um navegador se conecta a um servidor da WebHTTPS, o servidor apresenta um certificado para o navegador verificar sua lista de confiáveisCAs. Se o assinante estiver na lista ou for acessível por meio de uma cadeia de confiança que consiste em outros assinantes confiáveis, o navegador negociará um canal rápido de dados criptografados com o servidor e carregará a página.

Geralmente, os certificados são caros devido ao trabalho envolvido na validação das solicitações, portanto, vale a pena comparar os preços. Alguns CAs oferecem certificados de nível básico gratuitamente. O mais notável deles CAs é o projeto Let's Encrypt, que também suporta a automação do processo de criação e renovação de certificados. Para obter mais informações sobre como usar um certificado Let’s Encrypt, consulte Obtenção do Certbot.

Se você planeja oferecer serviços de nível comercial, o AWS Certificate Manager é uma boa opção.

É importante ter um certificado de host subjacente. A partir de 2019, grupos governamentais e setoriais recomendam o uso de um tamanho mínimo de chave (módulo) de 2048 bits para RSA chaves destinadas a proteger documentos até 2030. O tamanho do módulo padrão gerado pelo Open SSL em AL2 023 é de 2048 bits, o que é adequado para uso em um certificado assinado pela CA. No procedimento a seguir, uma etapa opcional é fornecida para aqueles que desejam uma chave personalizada, por exemplo, uma com módulo maior ou que usa um algoritmo diferente de criptografia.

Importante

Essas instruções para adquirir um certificado de host assinado pela CA não funcionam, a menos que você possua um domínio registrado e hospedado. DNS

Para obter um certificado assinado por uma CA
  1. Conecte-se à sua instância e navegue por to /etc/pki/tls/private /. Esse é o diretório em que você armazena a chave privada do servidorTLS. Se você preferir usar uma chave de host existente para gerar oCSR, vá para a Etapa 3. Para obter mais informações sobre como se conectar à sua instância, consulte Conexão com AL2 203 instâncias

  2. (Opcional) Gerar uma nova chave privada. Estes são alguns exemplos de configurações de chave. Qualquer uma das chaves resultantes funciona com seu servidor Web, mas elas variam no grau e no tipo de segurança que elas implementam.

    • Exemplo 1: Crie uma chave de RSA host padrão. O arquivo resultante,custom.key, é uma chave privada de 2048 bitsRSA.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key
    • Exemplo 2: Crie uma RSA chave mais forte com um módulo maior. O arquivo resultante,custom.key, é uma chave privada de 4096 bitsRSA.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
    • Exemplo 3: Crie uma RSA chave criptografada de 4096 bits com proteção por senha. O arquivo resultante,custom.key, é uma chave RSA privada de 4096 bits criptografada com a AES cifra -128.

      Importante

      A criptografia da chave fornece maior segurança, mas como uma chave criptografada requer uma senha, os serviços que dependem dela não podem ser iniciados automaticamente. Sempre que usar essa chave, você deverá fornecer a senha (no exemplo anterior, “abcde12345") por meio de uma conexão. SSH

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
    • Exemplo 4: Crie uma chave usando uma não RSA cifra. RSAa criptografia pode ser relativamente lenta devido ao tamanho de suas chaves públicas, que são baseadas no produto de dois grandes números primos. No entanto, é possível criar chaves para TLS que usem RSA não-cifras. As chaves baseadas em matemática de curvas elípticas são menores e computacionalmente mais rápidas para fornecer um nível de segurança equivalente.

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

      O resultado é uma chave privada de curva elíptica de 256 bits usando prime256v1, uma “curva nomeada” suportada pelo Open. SSL Sua força criptográfica é um pouco maior do que uma RSA chave de 2048 bits, de acordo com. NIST

      nota

      Nem todos CAs oferecem o mesmo nível de suporte para elliptic-curve-based chaves e para RSA chaves.

    Verifique se a nova chave privada tem a propriedade e permissões altamente restritivas (owner=root, group=root, leitura/gravação para o proprietário somente). O comando será o mostrado no exemplo a seguir.

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

    Os comandos anteriores produzem o resultado a seguir.

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

    Depois de criar e configurar uma chave satisfatória, você pode criar umaCSR.

  3. Crie um CSR usando sua chave preferida. O exemplo a seguir usa custom.key.

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

    Abrir SSL abre uma caixa de diálogo e solicita as informações mostradas na tabela a seguir. Todos os campos, exceto Common Name (Nome comum), são opcionais para um certificado de host básico validado por domínio.

    Nome Descrição Exemplo
    Nome do país A ISO abreviatura de duas letras do seu país. US (=Estados Unidos)
    Nome do estado ou província O nome do estado ou província onde sua organização está localizada. Este nome não pode ser abreviado. Washington
    Nome da localidade A localização de sua organização, como uma cidade. Seattle
    Nome da organização A razão social completa da sua organização. Não abrevie o nome de sua organização. Corporação de exemplo
    Nome da unidade organizacional Informações organizacionais adicionais, se houver. Departamento de exemplo
    Nome comum

    Esse valor deve corresponder exatamente ao endereço Web que você espera que os usuários digitem em um navegador. Geralmente, isso significa um nome de domínio com um nome de host ou alias prefixados na forma www.example.com. Em testes com um certificado autoassinado e sem DNS resolução, o nome comum pode consistir apenas no nome do host. CAstambém oferecem certificados mais caros que aceitam nomes curingas, como. *.example.com

    www.exemplo.com
    Endereço de e-mail O endereço de e-mail do administrador do servidor. someone@example.com

    Por fim, o Open SSL solicita que você forneça uma senha de desafio opcional. Essa senha se aplica somente às CSR e às transações entre você e sua CA, portanto, siga as recomendações da CA sobre esse e o outro campo opcional, nome opcional da empresa. A senha de CSR desafio não tem efeito na operação do servidor.

    O arquivo resultante csr.pem contém sua chave pública, a assinatura digital de sua chave pública e os metadados que você inseriu.

  4. CSREnvie-os para uma CA. Isso geralmente consiste em abrir seu CSR arquivo em um editor de texto e copiar o conteúdo em um formulário da web. No momento, você pode ser solicitado a fornecer um ou mais nomes alternativos de assunto (SANs) para serem colocados no certificado. Se www.example.com é o nome comum, então example.com seria bomSAN, e vice-versa. Um visitante de seu site que digitar qualquer um desses nomes verá uma conexão livre de erros. Se o formulário web da CA permitir, inclua o nome comum na lista deSANs. Alguns o CAs incluem automaticamente.

    Depois que sua solicitação é aprovada, você recebe um novo certificado de host assinado pela CA. Você também pode receber uma instrução para fazer download de um arquivo de certificado intermediário que contém os certificados adicionais necessários para concluir a cadeia de confiança da CA.

    nota

    Sua CA pode enviar a você arquivos em vários formatos com várias finalidades. Neste tutorial, você só deve usar um arquivo de certificado em PEM formato, que geralmente (mas nem sempre) está marcado com uma extensão de .crt arquivo .pem ou. Se você não tiver certeza sobre qual arquivo usar, abra os arquivos com um editor de texto e localize um que contenha um ou mais blocos com a linha a seguir.

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

    O arquivo também deve terminar com a linha a seguir.

    - - - -END CERTIFICATE - - - - -

    Você também pode testar um arquivo na linha de comando da forma a seguir.

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

    Verifique se as linhas aparecem no arquivo. Não use os arquivos que terminam com .p7b, .p7c ou extensões de arquivo semelhantes.

  5. Coloque o novo certificado assinado pela CA e quaisquer certificados intermediários no diretório /etc/pki/tls/certs.

    nota

    Há várias maneiras de fazer o upload do seu novo certificado para sua EC2 instância, mas a maneira mais direta e informativa é abrir um editor de texto (por exemplo, vi, nano ou bloco de notas) no computador local e na instância e, em seguida, copiar e colar o conteúdo do arquivo entre eles. Você precisa de permissões root [sudo] ao realizar essas operações na EC2 instância. Dessa forma, você vê imediatamente se há algum problema de permissão ou de caminho. No entanto, tenha cuidado para não adicionar mais linhas ao copiar o conteúdo ou ao alterá-lo de alguma maneira.

    De dentro do /etc/pki/tls/certs diretório, verifique se as configurações de propriedade, grupo e permissão do arquivo correspondem aos padrões AL2 023 altamente restritivos (proprietário = raiz, grupo = raiz, leitura/gravação somente para o proprietário). O exemplo a seguir mostra os comandos a serem usados.

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

    Esses comandos devem produzir o resultado a seguir.

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

    As permissões para o arquivo de certificado intermediário são menos estritas (owner=root, group=root, proprietário pode gravar, grupo pode ler, mundo pode ler). O exemplo a seguir mostra os comandos a serem usados.

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

    Esses comandos devem produzir o resultado a seguir.

    -rw-r--r-- root root intermediate.crt
  6. Coloque a chave privada que você usou para criar o CSR no /etc/pki/tls/private/ diretório.

    nota

    Há várias maneiras de fazer upload da chave personalizada para a EC2 instância, mas a forma mais direta e informativa é abrir um editor de texto (por exemplo, vi, nano ou bloco de notas) no computador local e na instância e, em seguida, copiar e colar o conteúdo do arquivo entre eles. Você precisa de permissões root [sudo] ao realizar essas operações na EC2 instância. Dessa forma, você vê imediatamente se há algum problema de permissão ou de caminho. No entanto, tenha cuidado para não adicionar mais linhas ao copiar o conteúdo ou ao alterá-lo de alguma maneira.

    De dentro do /etc/pki/tls/private diretório, use os comandos a seguir para verificar se as configurações de propriedade, grupo e permissão do arquivo correspondem aos padrões AL2 023 altamente restritivos (owner=root, group=root, leitura/gravação somente para proprietário).

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

    Esses comandos devem produzir o resultado a seguir.

    -rw------- root root custom.key
  7. Edite /etc/httpd/conf.d/ssl.conf para refletir seu novo certificado e arquivos de chave.

    1. Forneça o caminho e o nome do arquivo do certificado de host assinado por CA na diretiva SSLCertificateFile do Apache:

      SSLCertificateFile /etc/pki/tls/certs/custom.crt
    2. Se você receber um arquivo de certificado intermediário (intermediate.crt neste exemplo), forneça o caminho e o nome do arquivo usando a diretiva SSLCACertificateFile do Apache:

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

      Alguns CAs combinam o certificado do host e os certificados intermediários em um único arquivo, tornando a SSLCACertificateFile diretiva desnecessária. Consulte as instruções fornecidas pela CA.

    3. Forneça o caminho e o nome do arquivo da chave privada (custom.key neste exemplo) na diretiva SSLCertificateKeyFile do Apache:

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. Salve o /etc/httpd/conf.d/ssl.conf e reinicie o Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
  9. Teste seu servidor inserindo seu nome de domínio em uma URL barra do navegador com o prefixohttps://. Seu navegador deve carregar a página de teste HTTPS sem gerar erros.

Etapa 3: testar e intensificar a configuração de segurança

Depois de estar operacional e exposto ao público, você deve testar o quão seguro ele realmente é. TLS Isso é fácil de fazer usando serviços on-line, como o Qualys SSL Labs, que realiza uma análise gratuita e completa de sua configuração de segurança. Com base nos resultados, você pode decidir intensificar a configuração de segurança padrão controlando quais protocolos você aceita, quais cifras você prefere e quais você exclui. Para obter mais informações, consulte como a Qualys formula suas pontuações.

Importante

Os testes no mundo real são cruciais para a segurança do servidor. Pequenos erros de configuração podem resultar em rupturas de segurança sérias e em perda de dados. Como as práticas de segurança recomendadas são alteradas constantemente em resposta a pesquisas e a ameaças emergentes, auditorias periódicas da segurança são essenciais para uma boa administração do servidor.

No site da Qualys SSL Labs, insira o nome de domínio totalmente qualificado do seu servidor, no formuláriowww.example.com. Depois de dois minutos, você recebe uma classificação (de A a F) para seu site e um detalhamento dos resultados. A tabela a seguir resume o relatório de um domínio com configurações idênticas à configuração padrão do Apache em AL2 023 e com um certificado padrão do Certbot.

Classificação geral B
Certificado 100%
Suporte ao protocolo 95%
Troca de chaves 70%
Intensidade da cifra 90%

Embora a visão geral mostre que a configuração é mais sólida, o relatório detalhado sinaliza vários possíveis problemas, listados aqui em ordem de gravidade:

A RC4 cifra é compatível com o uso de alguns navegadores mais antigos. Uma cifra é o núcleo matemático de um algoritmo de criptografia. RC4, uma cifra rápida usada para criptografar TLS fluxos de dados, é conhecida por ter várias fraquezas graves. A menos que você tenha boas razões para oferecer suporte a navegadores legados, você deve desabilitar isso.

TLSVersões antigas são suportadas. A configuração suporta TLS 1.0 (já obsoleto) e TLS 1.1 (em um caminho para a descontinuação). Apenas TLS 1,2 foi recomendado desde 2018.

O sigilo de encaminhamento não é totalmente compatível. O sigilo encaminhado é um recurso de algoritmos que criptografam usando chaves de sessão temporárias (efêmeras) derivadas da chave privada. Isso significa, na prática, que os invasores não podem descriptografar HTTPS dados, mesmo que possuam a chave privada de longo prazo de um servidor web.

Para corrigir e preparar a configuração para o futuro TLS
  1. Abra o arquivo de configuração /etc/httpd/conf.d/ssl.conf em um editor de texto e comente as seguintes linhas digitando “#” no início delas.

    #SSLProtocol all -SSLv3
  2. Adicione a seguinte diretiva:

    #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Essa diretiva desabilita explicitamente SSL as versões 2 e 3, bem como TLS as versões 1.0 e 1.1. O servidor agora se recusa a aceitar conexões criptografadas com clientes usando qualquer coisa, exceto TLS 1.2. A expressão detalhada na diretriz transmite mais claramente, para um leitor humano, para que o servidor está configurado.

    nota

    Desabilitar TLS as versões 1.0 e 1.1 dessa maneira impede que uma pequena porcentagem de navegadores desatualizados acessem seu site.

Para modificar a lista de cifras permitidas
  1. No arquivo de configuração /etc/httpd/conf.d/ssl.conf, localize a seção com a diretiva SSLCipherSuite e comente a linha existente ao inserir "#" no início dela.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  2. Especifique conjuntos de criptografia explícitos e uma ordem de cifra que priorize o sigilo antecipado e evite cifras inseguras. A SSLCipherSuite diretiva usada aqui é baseada na saída do Mozilla SSL Configuration Generator, que adapta uma TLS configuração ao software específico executado em seu servidor. Primeiro, determine suas SSL versões do Apache e do Open usando a saída dos comandos a seguir.

    [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl

    Por exemplo, se as informações retornadas forem Apache 2.4.34 e Open SSL 1.0.2, inserimos isso no gerador. Se você escolher o modelo de compatibilidade "moderno", isso criará uma diretiva SSLCipherSuite que impõe a segurança de forma agressiva, mas ainda funciona para a maioria dos navegadores. Se o software não oferecer suporte à configuração moderna, você poderá atualizá-lo ou escolher a configuração "intermediária".

    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

    As cifras selecionadas têm ECDHEem seus nomes uma abreviatura de Elliptic Curve Diffie-Hellman Ephemeral. O termo ephemeral (efêmera) indica forward secrecy. Como subproduto, essas cifras não são compatíveis. RC4

    Recomendamos que você use uma lista explícita de cifras em vez de confiar em padrões ou em diretrizes concisas cujo conteúdo não é visível.

    Copie a diretiva gerada em /etc/httpd/conf.d/ssl.conf.

    nota

    Embora sejam mostradas em várias linhas aqui para facilitar a leitura, a diretriz deve estar em uma única linha quando copiada para /etc/httpd/conf.d/ssl.conf com apenas dois pontos (sem espaços) entre os nomes das cifras.

  3. Por fim, remova o comentário da linha a seguir, excluindo o "#" no início dela.

    #SSLHonorCipherOrder on

    Essa diretriz força o servidor a preferir cifras de alta classificação incluindo (neste caso) aquelas que oferecem suporte a forward secrecy. Com essa diretriz ativada, o servidor tenta estabelecer uma conexão altamente segura antes de voltar a usar cifras permitidas com menos segurança.

Depois de concluir esses dois procedimentos, salve as alterações em /etc/httpd/conf.d/ssl.conf e reinicie o Apache.

Se você testar o domínio novamente no Qualys SSL Labs, verá que a RC4 vulnerabilidade e outros avisos desapareceram e que o resumo se parece com o seguinte.

Classificação geral A
Certificado 100%
Suporte ao protocolo 100%
Troca de chaves 90%
Intensidade da cifra 90%

Cada atualização do Open SSL introduz novas cifras e remove o suporte para as antigas. Mantenha sua instância EC2 AL2 023 up-to-date, fique atento aos anúncios de segurança da Open SSL e fique atento às denúncias de novas falhas de segurança na imprensa técnica.

Solução de problemas

  • Meu servidor da web do Apache não inicia, a menos que eu digite uma senha.

    Esse é comportamento esperado se você tiver instalado uma chave privada de servidor criptografada e protegida por senha.

    Você pode remover a criptografia e a solicitação de senha da chave. Supondo que você tenha uma RSA chave criptografada privada chamada custom.key no diretório padrão e que a senha nela estejaabcde12345, execute os comandos a seguir na sua EC2 instância para gerar uma versão não criptografada da chave.

    [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 systemctl restart httpd

    O Apache agora deve iniciar sem solicitar uma senha a você.

  • Obtenho erros ao executar sudo dnf install -y mod_ssl.

    Ao instalar os pacotes necessários paraSSL, você pode ver erros semelhantes aos seguintes.

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    Isso normalmente significa que sua EC2 instância não está executando AL2 023. Este tutorial só oferece suporte a instâncias recém-criadas a partir de um AL2 AMI 023 oficial.