Aprenda a configurar o Apache com SSL (Parte III) – Final

7 Comentários

Nos dias que correm, é importante que todos os dados sensíveis transaccionados entre um cliente e um servidor sejam cifrados de modo a que estes não possam ser entendidos por terceiros. Na prática, quando acedemos a um serviço online que nos solicita dados pessoais ou credenciais de acesso (ex. sites de bancos) é importante que a toda a informação passada seja cifrada de modo a tornar-se ilegível. No caso dos servidor Web (entre outros serviços de uma rede), uma das formas de proceder a cifra dos dados é recorrendo ao protocolo SSL.

ssl_00

Depois de termos deixado aqui uma breve descrição sobre o que são chaves privadas e chaves publicas, um certificado digital, o protocolo SSL e o OpenSSL, e de termos aprendido aqui a produzir certificados digitais, hoje vamos finalizar esta sessão de tutoriais, explicando como se configura o Apache com o protocolo SSL (recorrendo aos certificados já criados).

Para quem não conhece, o Apache foi desenvolvido pela Apache Software Foundation e é o servidor WWW mais popular, tendo suporte para a maioria dos sistemas operativos. Além de muitas outras funcionalidades, o Apache tem suporte para o protocolo SSL através da activação de um modulo específico.

No CentOS o principal ficheiro de configuração do Apache encontra-se em /etc/httpd/conf/httpd.conf. Dentro do directório /etc/httpd/conf.d/ podemos proceder à configuração dos módulos.

Como instalar o mod_ssl?

Como referido, o Apache tem suporte para SSL através do modulo mod_ssl. Para instalar o modulo mod_ssl basta executar o comando:

yum install mod_ssl

Após a instalação é criado automaticamente o ficheiro /etc/httpd/conf.d/ssl.conf, onde podemos realizar as configuração associadas ao SSL. Usando o ficheiro já criado, apenas necessitamos de indicar os seguintes paramentos:

  • SSLCertificateFile /etc/pki/tls/pplware/www.crt
  • SSLCertificateKeyFile /etc/pki/tls/pplware/chaveprivada.key

Nota: De referir, que os ficheiros foram produzidos com base no processo descrito neste artigo

##
## SSL Virtual Host Context
##



# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443

# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2
#   SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
#SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateFile /etc/pki/tls/pplware/www.crt
SSLCertificateKeyFile /etc/pki/tls/pplware/chaveprivada.key
SSLVerifyClient require 
SSLVerifyDepth  10 …. 

Após a configuração, apenas temos de reiniciar o Apache (service httpd restart) e verificar se tudo está a funcionar correctamente. Para isso, basta que abram um browser e estabelecem ligação ao servidor.

ssl_01Como podemos ver pela imagem anterior, a ligação estabelecida ao servidor é segura, sendo usado o protocolo TLS. Relativamente ao aviso “O certificado do servidor não é fidedigno” tal acontece porque o  browser não conhece a nossa autoridade de certificação. Para tal, no primeiro aviso basta que indiquem que confiam na  autoridade de certificação e que pretendem prosseguir.

Esperamos que este conjunto de 3 tutoriais vos sejam úteis, e que a partir de agora possam implementar servidores Apache seguros. O processo de criação de certificados é idêntico para outros serviços da rede como por exemplo e-Mail, FTP, etc. Alguma duvida ou questão, basta deixar nos comentários deste artigo.

Partilhar:
Tags:

Comentários

7

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

  1. Avatar de Nuno Silva
    Nuno Silva

    Para quando um tutorial para reverse proxy?

  2. Avatar de Pedro H
    Pedro H

    Apenas só faltava mesmo o tutorial para meter certificados do cartão de cidadão e configurar o OCSP para as listas de revogação :p

    De qualquer das formas, bom trabalho Pedro.
    Vou arranhar hoje á noite no meu servidor ehehehehhe

  3. Avatar de Feijao

    Hi,

    obrigado, mais logo vou experimentar numa nova VM

    Cheers,
    AF

    1. Avatar de Pedro Pinto

      Depois da feedback 🙂

  4. Avatar de Mim
    Mim

    E para quem quiser aprender a configurar os seus servidores de forma mais segura:

    https://calomel.org/ssl_certs.html (pode estar temporariamente indisponível de quando em quando)

    e

    https://www.ssllabs.com/projects/index.html

    Resumidamente, e para que dá prioridade máxima à segurança, não à performance.

    Para um nível de segurança de 128 bits* (até pelo menos 2030):

    – Chaves RSA privadas de 4096 bits com algoritmo de integridade (hash) SHA256. Ou chave privada EC de 256 bits com algoritmo de integridade (hash) SHA256. (Chaves privadas EC não é possível ser ainda autenticadas por nenhuma autoridade certificadora).
    – Algoritmos de 128 bits como o Camellia-128, AES-128 e RC4-128.
    – Usarem os protocolos de troca de chave ECDH (preferível) e DHE (segunda escolha), e de preferência nenhum outro, porque este criam uma código único para cada ligação, mesmo que alguém seja capaz de desencriptar uma ligação, não conseguirá desencriptar as outras usando o mesmo código. ECDH com módulo de 256 bits ou DHE com módulo de 4096 bits.
    – Protocolos de encriptação TLS 1.1 e TLS 1.2 e nenhum outro.

    Para um nível de segurança de 192 bits* (até algum tempo depois de 2030):

    – Chaves RSA privadas de 8192 bits com algoritmo de integridade (hash) SHA384. Ou chave privada EC de 384 bits com algoritmo de integridade (hash) SHA384. (Chaves privadas EC não é possível ser ainda autenticadas por nenhuma autoridade certificadora).
    – Algoritmos de 256 bits como o Camellia-256, AES-256.
    – Usarem os protocolos de troca de chave ECDH (preferível) e DHE (segunda escolha), e de preferência nenhum outro, porque este criam uma código único para cada ligação, mesmo que alguém seja capaz de desencriptar uma ligação, não conseguirá desencriptar as outras usando o mesmo código. ECDH com módulo de 384 bits ou DHE com módulo de 8192 bits.
    – Protocolos de encriptação TLS 1.1 e TLS 1.2 e nenhum outro.

    Para um nível de segurança de 256 bits* (até algum tempo depois de 2040):

    – Chave privada EC de 512 bits com algoritmo de integridade (hash) SHA512. (Chaves privadas EC não é possível ser ainda autenticadas por nenhuma autoridade certificadora).
    – Algoritmos de 256 bits como o Camellia-256, AES-256.
    – Usarem o protocolo de troca de chave ECDH e de preferência nenhum outro, porque este cria uma código único para cada ligação, mesmo que alguém seja capaz de desencriptar uma ligação, não conseguirá desencriptar as outras usando o mesmo código. ECDH com módulo de 512 bits.
    – Protocolo de encriptação TLS 1.2 e nenhum outro.

    * nível de segurança comprometido se existir, ou vier a existir tecnologia processamento computorizado de nível quântico, que será capaz de quebrar a segurança das chaves privadas RSA e EC instantaneamente devido à forma como funciona. Alternativas futuras poderão ser o Lamport, McEliece ou NTRU… parecendo de momento que McEliece aquele que melhor se adequará no futuro apesar de alguns problemas (não aplicáveis na pratica a PC’s)
    Fontes:
    http://middleware.internet2.edu/idtrust/2009/papers/07-perlner-quantum.pdf
    http://www.keylength.com/

    Notas adicionais:
    – Usarem chaves RSA de 4096 bits tem um impacto na quantidade de clientes que se podem ligar ao servidor, contudo é a única maneira de garantirem um nível de segurança de 128 bits.
    – Provavelmente devido a problemas de patentes, nenhuma autoridade certificadora se disponibiliza a assinar certificado EC, apesar de algumas já terem a chave pública presente nos repositórios de chaves dos browsers. Quando ficarem disponíveis, deverão ser preferidas, dado que irão aumentar a segurança e reduzir o impacto no servidor.

  5. Avatar de José Maria Oliveira Simões
    José Maria Oliveira Simões

    Neste url há um pdf sobre o tema. http://www.dedoimedo.com/computers/apache_book_part.html
    Por falar em segurança, no url que se segue, mostra o que se deve fazer para se continuar seguro na net. http://www.osnews.com/story/25718/How_to_remain_safe_on_the_road