Como ativar o HTTPS nos seus servidores

Chris Palmer

Matt Gaunt

Twitter Página inicial

Etapas abordadas neste artigo

1. Crie um par de chaves pública/privada RSA de 2048 bits.
2. Gere uma solicitação de assinatura de certificado (CSR, na sigla em inglês) que incorpore sua chave pública.
3. Compartilhe a CSR com a autoridade certificadora (CA, na sigla em inglês) para receber um certificado final ou uma cadeia de certificados.
4. Instale 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/públicas e uma CSR.

Gerar um par de chaves pública/privada

Vamos começar gerando um par de chaves RSA de 2.048 bits. Uma chave menor, como 1.024 bits, não tem resistência suficiente contra ataques de força bruta. Uma chave maior, como 4.096 bits, é um exagero. Com o tempo, o tamanho da chave aumenta conforme o processamento de computador fica mais barato. Atualmente,o tamanho ideal é 2.048.

O comando para gerar o par de chaves RSA é:

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

O resultado será o seguinte:

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

Gerar uma solicitação de assinatura de certificado

Nesta etapa, você vai incorporar a chave pública e as informações sobre sua organização e seu site em uma solicitação de assinatura de certificado (CSR, na sigla em inglês). O comando openssl solicita, de maneira interativa, os metadados necessários.

Execute o 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

E 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 de certificação (CAs) exigem métodos distintos para enviar CSRs. Esses métodos podem incluir o uso de um formulário no site, o envio da CSR por e-mail ou outro método. Algumas CAs (ou seus revendedores) podem até mesmo automatizar alguns ou todos os processos (incluindo, em alguns casos, par de chaves e geração de CSR).

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

CAs diferentes 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.

Por exemplo, uma CA oferece estes preços no momento:

• Padrão: US$ 16/ano, válido para example.com e www.example.com.
• Curinga: US$ 150/ano, válido para example.com e *.example.com.

Com esses preços, os certificados de caractere curinga são econômicos quando você tem mais de nove subdomínios. Caso contrário, é possível comprar apenas um ou mais certificados de nome único. Se você tiver mais de cinco subdomínios, por exemplo, talvez encontre um certificado de caractere curinga mais conveniente ao ativar o HTTPS nos servidores.

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

Ativar HTTPS nos seus servidores

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

• Use a ferramenta de configuração de servidor do Mozilla para configurar o servidor para oferecer suporte a HTTPS.
• Teste seu site regularmente com o prático 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 exclusivo a cada nome de host usado pelo servidor da Web para exibir conteúdo.
• Use hospedagem virtual baseada em nome.

Se você estiver usando endereços IP distintos para cada nome de host, será fácil oferecer suporte a HTTP e HTTPS para todos os clientes.

No entanto, a maioria dos operadores de site usa hospedagem virtual baseada em nome para economizar endereços IP e por ser mais conveniente em geral. O problema do IE no Windows XP e do Android anteriores à 2.3 é que eles não entendem a indicação de nome do servidor (SNI, na sigla em inglês), que é crucial para a hospedagem virtual baseada em nome HTTPS.

Algum dia (esperamos que em breve) os clientes incompatíveis com a SNI sejam substituídos por software moderno. Monitore a string do user agent nos registros de solicitação para saber quando uma parcela suficiente da população de usuários migrou para um software moderno. Você pode decidir qual é seu limite, talvez menos de 5% ou menos de 1%.

Se você ainda não tem o serviço HTTPS disponível nos seus servidores, ative-o agora (sem redirecionar o HTTP para HTTPS; veja abaixo). 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, cada um deles precisará usar o certificado correto.

Verifique a configuração HTTPS com o teste prático de servidor SSL da Qualys durante todo o ciclo de vida do seu site. A pontuação do site precisa ser A ou A+. Trate tudo que causa uma nota mais baixa como um bug. O A de hoje é o B de amanhã, porque os ataques contra algoritmos e protocolos estão sempre melhorando.

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 independem do protocolo. Ou seja, use caminhos relativos ou deixe o protocolo de fora, como //example.com/something.js.

Ocorre um problema quando você disponibiliza uma página via HTTPS que inclui recursos HTTP, conhecidos como conteúdo misto. Os navegadores alertam os usuários que toda a força do HTTPS foi perdida. Na verdade, no caso de conteúdo misto ativo (scripts, plug-ins, CSS, iframes), os navegadores geralmente não carregam nem executam o conteúdo, o que resulta em uma página corrompida. Lembre-se, não há problema em incluir recursos HTTPS em uma página HTTP.

Além disso, quando você vincula a outras páginas no seu site, os usuários podem ser downgrades de HTTPS para HTTP.

Esses problemas acontecem quando as páginas incluem URLs internos do site totalmente qualificados que usam o esquema http://.

<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>

Em outras palavras, torne os URLs internos do site o mais relativos possível: relativos a protocolo (sem protocolo, começando com //example.com) ou relativos a host (começando apenas com o caminho, como /jquery.js).

<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>

<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>

<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>

Faça isso com um script, não manualmente. Caso o conteúdo do site esteja 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 em arquivos simples, teste seu 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. Use o script de Bram van Damme ou algo semelhante para detectar conteúdo misto no site.

Ao incluir links para outros sites (em vez de incluir os recursos deles), não altere o protocolo, já que você não tem controle sobre o funcionamento desses sites.

Para facilitar a migração de sites grandes, recomendamos URLs relacionados a protocolo. Se você não tem certeza se já consegue implantar totalmente o HTTPS, forçar o site a usar HTTPS para todos os recursos secundários pode não dar certo. Em um determinado período, o HTTPS será novo e estranho para você, e o site HTTP ainda precisará funcionar da melhor forma possível. Com o tempo, você concluirá a migração e bloqueará o HTTPS. Consulte as duas próximas seções.

Se o site depende de scripts, imagens ou outros recursos veiculados 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 o faça. A maioria já faz, incluindo jquery.com.
• Disponibilize os recursos de um servidor que você controla e que oferece HTTP e HTTPS. Muitas vezes, essa é uma boa ideia, porque você tem melhor controle sobre a aparência, o desempenho e a segurança do site. Além disso, você não precisa confiar em um terceiro, o que é sempre bom.

Redirecionar HTTP para HTTPS

É necessário inserir um link canônico no cabeçalho da página para informar aos mecanismos de pesquisa que a melhor maneira de acessar o site é o HTTPS.

Defina tags <link rel="canonical" href="https://…"/> nas suas páginas. Isso ajuda os mecanismos de pesquisa a determinar a melhor maneira de chegar ao seu site.

Ativar segurança de transporte estrita e cookies seguros

Agora, você está pronto para "bloquear" o uso de HTTPS.

• Use a segurança de transporte estrita do HTTP (HSTS) para evitar o custo do redirecionamento 301.
• Sempre defina o sinalizador de segurança nos cookies.

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

Ative o HTTP Strict Transport Security (HSTS) definindo o cabeçalho Strict-Transport-Security. A página HSTS do OWASP tem links para instruções (em inglês) para vários softwares de servidor.

A maioria dos servidores da Web oferece um recurso semelhante 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, a garantia de segurança de toda a sessão será destruída, mesmo que você tenha feito todo o resto corretamente.

Portanto, altere seu aplicativo da Web para sempre definir a flag "Seguro" nos cookies que ele define. Esta página do OWASP explica como definir a sinalização segura em vários frameworks de aplicativos. Cada framework de aplicativo tem uma forma de definir a 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 de HTTP para a versão HTTPS do seu 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 mantendo a classificação na pesquisa. O Bing também publica diretrizes para webmasters.

Performance

Quando as camadas de conteúdo e do aplicativo são bem ajustadas (consulte os livros de Steve Souders para ver um ótimo conselho), as preocupações restantes com o desempenho do TLS geralmente são pequenas em relação ao custo geral do aplicativo. Além disso, é possível reduzir e amortizar esses custos. Para um ótimo conselho sobre a otimização do TLS e em geral, consulte High Performance Browser Networking, de Ilya Grigorik. Consulte também o OpenSSL Cookbook (em inglês) de Ivan Ristic e o SSL e TLS à prova de bala (links em inglês).

Em alguns casos, o TLS pode melhorar o desempenho, principalmente como resultado de possibilitar o HTTP/2. Chris Palmer deu uma palestra sobre o desempenho de HTTPS e HTTP/2 na Chrome Dev Summit 2014.

Cabeçalhos de referência

Quando os usuários seguem links do 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 puderem concluir a seção Ativar HTTPS nos seus servidores deste guia, mude os links no seu site de http:// para https:// ou use links relativos a protocolo.
• Para contornar vários problemas com os cabeçalhos Referer, use o novo padrão da política de referenciadores (em inglês).

Como os mecanismos de pesquisa estão migrando para HTTPS, no futuro você provavelmente terá mais cabeçalhos Referer quando migrar para HTTPS.

Receita de anúncios

Os operadores de sites que geram receita com a exibição de 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. Há um problema complicado de ação coletiva aqui: até que os anunciantes publiquem por HTTPS, os operadores de sites não possam 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.

Os anunciantes precisam oferecer pelo menos um serviço de publicidade via HTTPS (por exemplo, completando a seção "Ativar HTTPS nos servidores" nesta página). Muitos já fazem isso. Pergunte aos anunciantes que não veiculam HTTPS que, pelo menos, comecem a usar. Talvez seja necessário adiar a conclusão da seção Tornar os URLs internos do site relativos até que um número suficiente de anunciantes interopere corretamente.