03 Jul 2011 às 21:31 0 1334 Tecnologia
O SSL (Secure Socket Layer) é o protocolo usado para criar páginas seguras, encriptando toda a transmissão entre o cliente e o servidor. Eles são os responsáveis pela efetividade do protocolo HTTPS e pelo tradicional cadeado nas páginas protegidas por ele.
Os dois usos mais comuns são em páginas de comércio eletrônico, onde é necessário oferecer um ambiente seguro para concluir a transação e transmitir dados confidenciais e também a criação de ambientes administrativos como os usados pela maioria dos gestores de conteúdo, onde você tem acesso ao conteúdo do site e por isso precisa acessar sem que outras pessoas possam capturar suas senhas e outras informações.
Certificados SSL podem ser gerados facilmente através do OpenSSL, que é a mesma biblioteca utilizada pelo SSH e por diversos outros sistemas de encriptação. Você mesmo pode gerar seu próprio certificado SSL rapidamente, em praticamente qualquer distribuição Linux usando o comando "openssl", como em:
# openssl req -new -x509 -days 1095 -sha1 -newkey rsa:1024 -nodes
-keyout server.key -out meuservidor.csr
Este comando gera dois arquivos separados, o "server.key", que contém a chave criptográfica e o "meuservidor.csr", que contém o certificado que será fornecido aos clientes. Para usá-los, você precisa apenas adicionar duas linhas separadas dentro da configuração do site (virtual host) dentro da configuração do Apache, especificando as localizações dos arquivos gerados:
SSLCertificateFile /etc/apache2/ssl/meuservidor.csr
SSLCertificateKeyFile /etc/apache2/ssl/server.key
Estes certificados caseiros são chamados de certificados self-signed (auto-assinados), já que você mesmo faz o papel de entidade certificadora, gerando e assinando o certificado. O algoritmo de encriptação usado é o mesmo, de forma que um certificado self-signed corretamente gerado oferece a mesma segurança que um certificado reconhecido. O grande problema é que os navegadores nos clientes não serão capazes de verificar a autenticidade do certificado, de forma que os visitantes receberão um aviso de "certificado não reconhecido" ao acessarem a página:
O propósito de entidades certificadoras, como a Verisign é confirmar a titularidade dos certificados, confirmando que o certificado recebido ao acessar determinado site pertence realmente à entidade que o está fornecendo. É isso que garante que você está mesmo acessando o home banking do banco em que tem conta e não o site de um script kiddie qualquer.
Certificados assinados por entidades certificadoras são automaticamente aceitos pelos navegadores (já que sua identidade já foi confirmada pela entidade certificadora), o que evita a exibição da mensagem. Ou seja, ao obter um certificado reconhecido, você obtém o selo de aprovação da entidade cerificadora, que comprova a autenticidade do seu site e passa a oferecer um certo nível de garantia contra fraudes. É por isso que um certificado reconhecido é praticamente um pré-requisito para qualquer página de comércio eletrônico.
Uma das entidades certificadoras mais tradicionais é a Verisign (http://www.verisign.com/), que oferece uma série de garantias sobre os certificados emitidos. O grande problema com relação à Verisign é o preço: o certificado de validação mais simples custa nada menos de US$ 499 anuais, com opções de até US$ 1499:
Com preços tão altos, não é de se estranhar que existam inúmeras outras entidades certificadoras menores, que oferecem preços mais competitivos.
Alguns exemplos são a Thawte (http://www.thawte.com) a GeoTrust (http://www.geotrust.com), a NetworkSolutions (http://www.networksolutions.com), a Digicert (http://www.digicert.com/) e a Comodo (http://www.instantssl.com), que possui opções a partir de US$ 79 anuais.
A Comodo é a mesma empresa que desenvolve o Comodo Firewall, distribuído gratuitamente como uma forma de divulgação dos serviços de certificação. No site está disponível também a opção de gerar um certificado de teste (válido por 90 dias) gratuitamente, que você pode usar para fins de teste, ou quando quiser colocar uma loja virtual no ar rapidamente, deixando para aderir a um dos planos pagos mais tarde:
Existem ainda casos de empresas que oferecem certificados de baixo custo, como a Godaddy (http://www.godaddy.com, a mesma que faz registro de domínios), que oferece certificados a partir de US$ 29.90:
Em termos de segurança, não existe muita diferença entre um certificado emitido pela Godaddy ou pela Verisign, as principais diferenças são o nível de validação e as garantias oferecidas por cada uma em caso de fraude ou de quebra da chave criptográfica. Assim como em outras áreas, o principal fator na decisão acaba sendo a questão da confiança.
Muitos serviços de hospedagem oferecem a possibilidade de utilizar um certificado compartilhado, onde a empresa responsável "empresta" seu próprio certificado para uso dos clientes, em troca de uma taxa de manutenção anual. Esta opção pode parecer interessante devido ao baixo custo e à facilidade de implementação, mas não é o mesmo que obter seu próprio certificado, já que muito provavelmente você precisará hospedar seu site em um subdomínio e os clientes verão o nome da empresa de hospedagem (e não o nome da sua empresa) ao examinarem as propriedades do certificado.
Existe ainda a possibilidade de obter também um certificado gratuito no http://www.cacert.org/. Ele é reconhecido pela CAcert, mas o certificado raiz deles não vem pré-instalado na maioria dos navegadores, o que faz com que os clientes continuem recebendo a mensagem de certificado não válido ao acessar o servidor, de forma similar ao que temos ao usar um certificado self-signed.
Ao contratar os serviços de uma entidade certificadora, sua parte no trabalho é a de gerar uma chave de encriptação e uma requisição de certificado, o que é novamente feito usando o openssl:
# openssl req -new -nodes -keyout gdhn.key -out gdhn.csr
O "gdhn.key" e o "gdhn.csr" indicam os arquivos com a chave e com a requisição do certificado que serão gerados. Você precisará responder as mesmas perguntas sobre o país, estado, cidade, nome da empresa, etc., que precisam ser respondidos corretamente, já que as informações serão examinadas não apenas pela entidade certificadora, mas também pelos clientes:
Country Name (2 letter code) [AU]: BR
State or Province Name (full name) [Some-State]: Estado
Locality Name (eg, city) []: Cidade
Organization Name (eg, company) []: Minha Empresa LTDA
Organizational Unit Name (eg, section) []: Vendas
Common Name (eg, YOUR name) []: ssl.minhaempresa.com.br
O campo "Common Name" deve ser preenchido com o domínio onde o certificado será usado (incluindo o "www" ou o subdomínio usado), caso contrário os clientes receberão um aviso ao acessarem o site:
Em geral, as entidades certificadores oferecem a opção de obter um certificado curinga (wildcard), que cobre automaticamente todos os subdomínios usados no site. Entretanto, como eles abrem a possibilidade de usar vários subdomínios usando um único certificado, as certificadoras cobram bem mais caro por eles:
Depois de gerar a requisição, o próximo passo é enviar o arquivo .csr para a entidade certificadora, que o usará para gerar o certificado. O arquivo .csr é na verdade um arquivo de texto plano, cujo conteúdo pode ser copiado e colado em um formulário web. Depois de confirmada sua identidade e feito o pagamento, você receberá de volta o certificado assinado, que pode ser então usado na configuração do Apache.
A configuração consiste em adicionar as linhas "SSLCertificateFile" e "SSLCertificateKeyFile" indicando a localização do arquivo .crt e .key recebidos. Em muitos casos, você receberá também um terceiro arquivo, com extensão "ca-bundle" ou similar, que é usado em conjunto com uma terceira opção a "SSLCertificateChainFile". Este terceiro arquivo contém uma combinação de certificados que permitem aos clientes chegar até o certificado raiz da entidade certificadora, de forma a comprovarem a autenticidade do seu certificado ele é também chamado de certificado intermediário (Intermediate Certificate). Aqui temos um exemplo de configuração com as três opções:
DocumentRoot /var/www/gdhn
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
O processo de emissão do certificado inclui uma verificação de identidade, que é justamente um dos principais papéis da entidade certificadora, já que se qualquer um pudesse gerar certificados válidos no nome de qualquer outro, o sistema perderia completamente o sentido. Nos planos mais simples, como no certificado gratuito oferecido pela Comodo, é feita uma simples verificação de titularidade via e-mail, onde você deve confirmar um código enviado para uma conta administrativa, como "admin@meudominio" ou "hostmaster@meudominio". Nos planos mais caros (onde a entidade certificadora realmente oferece garantias, inclusive financeiras sobre o certificado emitido) o processo é mais burocrático, incluindo o envio de documentos.