Aprenda a configurar o Apache com SSL (Parte III) – Final
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.
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 ## <virtualhost _default_:443=""> # 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 …. </virtualhost> |
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.
Como 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.
Este artigo tem mais de um ano
Para quando um tutorial para reverse proxy?
offtopic
Á atenção dos mac fans:
550.000 maquinas infectadas
http://www.dailymail.co.uk/sciencetech/article-2125496/Rude-awakening-Mac-users-cyber-attack-infects-550-000-Apples-virus-free-machines.html
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
Hi,
obrigado, mais logo vou experimentar numa nova VM
Cheers,
AF
Depois da feedback 🙂
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.
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