Ativar o HTTPS nos seus servidores

Chris Palmer
Chris Palmer

Nesta página, você encontra orientações para configurar o HTTPS nos seus servidores, incluindo as seguintes etapas:

  • Como criar um par de chaves pública/privada RSA de 2048 bits.
  • gerar uma solicitação de assinatura de certificado (CSR, na sigla em inglês) que incorpora sua chave pública;
  • Compartilhar a CSR com a autoridade certificadora (CA) para receber um certificado final ou uma cadeia de certificados.
  • Instalando o certificado final em um local não acessível pela Web, como /etc/ssl (Linux e Unix) ou no local indicado pelo IIS (Windows).

Gerar chaves e solicitações de assinatura de certificado

Esta seção usa o programa de linha de comando OpenSSL, que vem com a maioria dos sistemas Linux, BSD e Mac OS X, para gerar chaves privadas e públicas e uma CSR.

Gerar um par de chaves pública/privada

Para começar, gere um par de chaves RSA de 2.048 bits. Uma chave mais curta pode ser quebrada por ataques de força bruta, e chaves mais longas usam recursos desnecessários.

Use o comando a seguir para gerar um par de chaves RSA:

openssl genrsa -out www.example.com.key 2048

A saída é a seguinte:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Gerar uma solicitação de assinatura de certificado

Nesta etapa, você incorpora a chave pública e as informações sobre sua organização e seu site em uma solicitação de assinatura de certificado, ou CSR. O comando openssl solicita os metadados necessários.

Executando o seguinte comando:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Produz o seguinte:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Para garantir a validade da CSR, execute este comando:

openssl req -text -in www.example.com.csr -noout

A resposta será semelhante a esta:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Enviar a CSR para uma autoridade certificadora

Diferentes autoridades certificadoras (CAs) exigem que você envie suas CSRs a elas de maneiras diferentes. Isso pode incluir usar um formulário no site ou enviar a CSR por e-mail. Algumas CAs ou os revendedores deles podem até automatizar alguns ou todos os processos, incluindo, em alguns casos, par de chaves e geração de CSR.

Envie a CSR para sua CA e siga as instruções para receber o certificado final ou a cadeia de certificados.

Diferentes CAs cobram valores distintos pelo serviço de confirmar sua chave pública.

Também há opções para mapear sua chave para mais de um nome DNS, incluindo vários nomes distintos (por exemplo, example.com, www.example.com, example.net e www.example.net) ou nomes com "caractere curinga", como *.example.com.

Copie os certificados para todos os servidores front-end em um local não acessível pela Web, como /etc/ssl (Linux e Unix) ou no local indicado pelo IIS (Windows).

Ative o HTTPS nos seus servidores

A ativação do HTTPS nos servidores é uma etapa essencial para proporcionar segurança às páginas da Web.

  • Use a ferramenta de configuração do servidor do Mozilla para configurar o servidor para oferecer suporte a HTTPS.
  • Teste seu site regularmente com o teste de servidor SSL da Qualys e garanta pelo menos um A ou A+.

Neste ponto, você precisa tomar uma decisão operacional crucial. Escolha uma das seguintes opções:

  • Dedique um endereço IP distinto para cada nome do host usado pelo servidor da Web para exibir conteúdo.
  • Usar hospedagem virtual baseada em nome.

Se você estiver usando endereços IP diferentes para cada nome de host, será possível oferecer suporte a HTTP e HTTPS para todos os clientes. No entanto, a maioria dos operadores de sites usa hospedagem virtual baseada em nome para economizar endereços IP e porque isso é mais conveniente em geral.

Se você ainda não tiver o serviço HTTPS disponível nos seus servidores, ative-o agora (sem redirecionar o HTTP para o HTTPS. Consulte Redirecionar HTTP para HTTPS para mais informações. Configure seu servidor da Web para usar os certificados que você comprou e instalou. O gerador de configuração do Mozilla pode ser útil.

Se você tiver muitos nomes de host ou subdomínios, todos eles precisarão usar o certificado correto.

Verifique a configuração HTTPS com o teste de servidor SSL da Qualys (link em inglês) durante todo o ciclo de vida do site. Seu site deve receber uma pontuação A ou A+. Trate tudo que causa uma nota menor como um bug e mantenha-se diligente, porque novos ataques contra algoritmos e protocolos estão sempre sendo desenvolvidos.

Tornar os URLs internos do site relativos

Agora que você está disponibilizando seu site em HTTP e HTTPS, tudo precisa funcionar da maneira mais tranquila possível, independentemente do protocolo. Um fator importante é usar URLs relativos para links internos do site.

Verifique se os URLs internos e externos do site não dependem de um protocolo específico. Use caminhos relativos ou deixe o protocolo de fora, como em //example.com/something.js.

Veicular uma página que contém recursos HTTP usando HTTPS pode causar problemas. Quando um navegador encontra uma página segura que usa recursos não seguros, ele avisa aos usuários que a página não é totalmente segura e alguns navegadores se recusam a carregar ou executar os recursos HTTP, o que interrompe a página. No entanto, você pode incluir recursos HTTPS em uma página HTTP com segurança. Para mais orientações sobre como corrigir esses problemas, consulte Como corrigir conteúdo misto.

Seguir links baseados em HTTP para outras páginas no site também pode fazer downgrade da experiência do usuário de HTTPS para HTTP. Para corrigir isso, torne os URLs internos do site o mais relativos possível, tornando-os relativos a protocolo (sem protocolo, começando com //example.com) ou relativos ao host (começando apenas com o caminho, como /jquery.js).

O que fazer
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
Use URLs internos do site relativos.
O que fazer
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
Ou use URLs internos do site relativos a protocolo.
O que fazer
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Use URLs HTTPS para links de outros sites sempre que possível.

Atualize seus links com um script, e não manualmente, para evitar erros. Se o conteúdo do seu site estiver em um banco de dados, teste seu script em uma cópia de desenvolvimento do banco de dados. Se o conteúdo do site consistir apenas em arquivos simples, teste o script em uma cópia de desenvolvimento dos arquivos. Envie as alterações para produção somente depois que elas passarem pelo controle de qualidade, como sempre. Você pode usar o script de Bram van Damme ou algo semelhante para detectar conteúdo misto no seu site.

Ao vincular outros sites (em vez de incluir recursos deles), não altere o protocolo. Você não tem controle sobre o funcionamento desses sites.

Para facilitar a migração de sites grandes, recomendamos URLs relativos a protocolo. Se você não tiver certeza se já pode implantar totalmente o HTTPS, forçar o site a usar HTTPS para todos os sub-recursos pode não dar certo. Provavelmente, haverá um período em que o HTTPS será novo e estranho para você, e o site HTTP ainda deverá funcionar bem como nunca. Com o tempo, você concluirá a migração e bloqueará o HTTPS (consulte as próximas duas seções).

Se o site depende de scripts, imagens ou outros recursos disponibilizados por terceiros, como CDN ou jquery.com, você tem duas opções:

  • Use URLs relativos a protocolo para esses recursos. Se o terceiro não disponibilizar HTTPS, peça que faça isso. A maioria já faz isso, incluindo o jquery.com.
  • Disponibilize os recursos de um servidor que você controla, que oferece HTTP e HTTPS. Isso geralmente é uma boa ideia, porque você tem mais controle sobre a aparência, o desempenho e a segurança do site, e não precisa confiar em um terceiro para mantê-lo seguro.

Redirecionar HTTP para HTTPS

Para instruir os mecanismos de pesquisa a usar HTTPS para acessar seu site, coloque um link canônico no cabeçalho de cada página usando tags <link rel="canonical" href="https://…"/>.

Ative a segurança de transporte estrita e os cookies seguros

Neste ponto, você está pronto para "bloquear" o uso de HTTPS:

  • Use o HTTP Strict Transport Security (HSTS) para evitar o custo do redirecionamento 301.
  • Sempre defina o flag Secure nos cookies.

Primeiro, use Strict Transport Security para informar aos clientes que eles precisam sempre se conectar ao seu servidor usando HTTPS, mesmo ao seguir uma referência http://. Isso evita ataques como SSL Stripping e evita o custo de ida e volta do 301 redirect que ativamos em Redirecionar HTTP para HTTPS.

Para ativar a HSTS, defina o cabeçalho Strict-Transport-Security. A página HSTS do OWASP tem links para instruções (em inglês) para vários tipos de software de servidor.

A maioria dos servidores da Web oferece recursos semelhantes para adicionar cabeçalhos personalizados.

Também é importante garantir que os clientes nunca enviem cookies (por exemplo, para autenticação ou preferências do site) por HTTP. Por exemplo, se o cookie de autenticação de um usuário for exposto em texto simples, sua garantia de segurança para toda a sessão será destruída, mesmo que você tenha feito tudo certo.

Para evitar isso, altere seu app da Web para sempre definir a sinalização "Secure" nos cookies. Nesta página do OWASP, explicamos como definir a flag segura em vários frameworks de apps. Cada framework de appl tem uma maneira de definir o flag.

A maioria dos servidores da Web oferece um recurso simples de redirecionamento. Use 301 (Moved Permanently) para indicar aos mecanismos de pesquisa e navegadores que a versão HTTPS é canônica e redirecione os usuários do HTTP para a versão HTTPS do site.

Classificação daesquisa

O Google usa HTTPS como um indicador positivo de qualidade da pesquisa. O Google também publica um guia sobre como transferir, mover ou migrar seu site enquanto mantém a classificação de pesquisa. O Bing também publica diretrizes para webmasters.

Desempenho

Quando as camadas de conteúdo e do aplicativo estão bem ajustadas (consulte os livros de Steve Souders para orientações), as preocupações restantes com o desempenho do TLS geralmente são pequenas em relação ao custo geral do aplicativo. Você também pode reduzir e amortizar esses custos. Para orientações sobre otimização do TLS, consulte Rede de navegadores de alto desempenho (em inglês), de Ilya Grigorik, bem como OpenSSL Cookbook (em inglês) de Ivan Ristic e bulletProof SSL and TLS (link em inglês).

Em alguns casos, o TLS pode melhorar o desempenho, principalmente como resultado da possibilidade do HTTP/2. Para mais informações, consulte a palestra de Chris Palmer sobre o desempenho em HTTPS e HTTP/2 no Chrome Dev Summit 2014 (em inglês).

Cabeçalhos de referência

Quando os usuários seguem links do seu site HTTPS para outros sites HTTP, os user agents não enviam o cabeçalho Referer. Se isso for um problema, há várias maneiras de resolvê-lo:

  • Os outros sites precisam migrar para HTTPS. Se os sites de referência concluírem a seção Ativar HTTPS nos seus servidores deste guia, você poderá mudar os links no seu site para os deles de http:// para https:// ou usar links relativos a protocolo.
  • Para contornar diversos problemas com os cabeçalhos Referer, use o novo padrão da política do referenciador (em inglês).

Receita de anúncios

Os operadores de site que geram receita com o site mostrando anúncios querem garantir que a migração para HTTPS não reduza as impressões de anúncios. No entanto, devido a questões de segurança de conteúdo misto, um <iframe> HTTP não funciona em uma página HTTPS. Até que os anunciantes publiquem por HTTPS, os operadores de sites não poderão migrar para HTTPS sem perder receita de publicidade. No entanto, até que eles migrem para HTTPS, os anunciantes terão pouca motivação para publicar HTTPS.

Para começar o processo de quebrar esse impasse, use anunciantes que oferecem serviços de publicidade por HTTPS e peça aos anunciantes que não veiculam HTTPS que não ofereçam HTTPS, pelo menos uma opção. Talvez seja necessário adiar a conclusão da seção Tornar relativos os URLs intrasite até que um número suficiente de anunciantes operem corretamente.