Esta página foi traduzida pela API Cloud Translation.

Ativar o HTTPS nos seus servidores

Chris Palmer

Matt Gaunt

Esta página oferece orientações para configurar o HTTPS nos seus servidores, incluindo as seguintes etapas:

Criação de um par de chaves pública/privada RSA de 2048 bits.
Gerar uma solicitação de assinatura de certificado (CSR) que incorpora sua chave pública.
Compartilhar sua CSR com a Autoridade certificadora (AC) para receber um certificado final ou uma cadeia de certificados.
Instalar o certificado final em um local não acessível pela Web, como /etc/ssl (Linux e Unix) ou onde o IIS exigir (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 adivinhação de força bruta, e chaves mais longas usam recursos desnecessários.

Use o seguinte comando para gerar um par de chaves RSA:

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

Isso gera o seguinte resultado:

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

Gerar uma solicitação de assinatura de certificado

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

Executando o seguinte comando:

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

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

Autoridades certificadoras (ACs) diferentes exigem que você envie CSRs para elas de maneiras diferentes. Isso pode incluir o uso de um formulário no site ou o envio do CSR por e-mail. Algumas ACs ou revendedores podem até automatizar parte ou todo o processo, incluindo, em alguns casos, a geração de pares de chaves e CSR.

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

Autoridades certificadoras diferentes cobram valores diferentes pelo serviço de garantia da sua chave pública.

Também há opções para mapear sua chave para mais de um nome de DNS, incluindo vários nomes distintos (por exemplo, todos os example.com, www.example.com, example.net e www.example.net) ou nomes "coringa", 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 onde o IIS (Windows) os exigir.

Ativar o HTTPS nos seus servidores

Ativar o HTTPS nos servidores é uma etapa essencial para garantir a segurança das suas páginas da Web.

Use a ferramenta de configuração de servidor da Mozilla para configurar o servidor para suporte a HTTPS.
Teste seu site regularmente com o SSL Server Test da Qualys e garanta que você receba pelo menos um A ou A+.

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

Dedique um endereço IP distinto a cada nome de host do servidor da Web que serve conteúdo.
Use a hospedagem virtual baseada em nome.

Se você estiver usando endereços IP distintos para cada nome de host, poderá oferecer suporte a HTTP e HTTPS para todos os clientes. No entanto, a maioria dos operadores de sites usa a hospedagem virtual com base em nome para conservar endereços IP e porque é mais conveniente em geral.

Se você ainda não tem 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 o 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.

Agora, e regularmente durante a vida útil do site, verifique a configuração HTTPS com o teste de servidor SSL do Qualys. Seu site precisa ter uma nota A ou A+. Trate qualquer coisa que cause uma nota mais baixa como um bug e fique atento, porque novos ataques contra algoritmos e protocolos estão sempre sendo desenvolvidos.

Tornar os URLs intrasite relativos

Agora que você está veiculando seu site em HTTP e HTTPS, as coisas precisam funcionar da maneira mais tranquila possível, independentemente do protocolo. Um fator importante é usar URLs relativos para links intrasite.

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

A veiculação de 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 os usuários de que a página não é totalmente segura. Além disso, alguns navegadores se recusam a carregar ou executar os recursos HTTP, o que quebra a página. No entanto, é possível incluir recursos HTTPS com segurança em uma página HTTP. 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 seu site também pode reduzir a experiência do usuário de HTTPS para HTTP. Para corrigir isso, torne seus URLs intrasite o mais relativo possível, tornando-os relativos a protocolos (sem um protocolo, começando com //example.com) ou relativos a hosts (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 relativos intrasite.

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 intrasite 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, não manualmente, para evitar erros. Se o conteúdo do seu site estiver em um banco de dados, teste o script em uma cópia de desenvolvimento do banco de dados. Se o conteúdo do seu site consistir apenas em arquivos simples, teste o script em uma cópia de desenvolvimento dos arquivos. Envie as mudanças para a produção somente depois que elas passarem pelo controle de qualidade, como de costume. Você pode usar o script de Bram van Damme ou algo semelhante para detectar conteúdo misto no seu site.

Ao criar links para outros sites (em vez de incluir recursos deles), não mude o protocolo. Você não tem controle sobre como esses sites funcionam.

Para facilitar a migração de sites grandes, recomendamos URLs relativos ao protocolo. Se você não tiver certeza se pode implantar totalmente o HTTPS, forçar seu site a usar HTTPS para todos os recursos secundários pode ser contraproducente. É provável que haja um período em que o HTTPS seja novo e estranho para você, e o site HTTP ainda precisa funcionar perfeitamente. Com o tempo, você vai concluir a migração e bloquear o HTTPS (consulte as duas próximas seções).

Se o site depender de scripts, imagens ou outros recursos veiculados por terceiros, como um CDN ou jquery.com, você terá duas opções:

Use URLs relativos a protocolo para esses recursos. Se o terceiro não oferecer HTTPS, peça para ele fazer isso. A maioria já faz isso, incluindo jquery.com.
Exiba os recursos de um servidor que você controla, que oferece HTTP e HTTPS. Essa é 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 terceiros para manter o site seguro.

Redirecionar HTTP para HTTPS

Para informar aos mecanismos de pesquisa que eles devem usar o HTTPS para acessar seu site, coloque um link canônico na cabeça de cada página usando tags <link rel="canonical" href="https://…"/>.

Ativar a segurança de transporte estrita e cookies seguros

Agora você já pode "bloquear" o uso do HTTPS:

Use a segurança de transporte restrito HTTP (HSTS, na sigla em inglês) para evitar o custo do redirecionamento 301.
Sempre defina a flag "Secure" em cookies.

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

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

A maioria dos servidores da Web oferece uma capacidade 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, sua garantia de segurança para toda a sessão será destruída, mesmo que você tenha feito tudo correto.

Para evitar isso, mude o app da Web para sempre definir a flag "Secure" nos cookies que ele define. Esta página do OWASP explica como definir a flag Secure em vários frameworks de apps. Cada framework de app tem uma maneira de definir a flag.

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

Classificação daesquisa

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

Desempenho

Quando as camadas de conteúdo e de aplicativo estão bem ajustadas (consulte livros de Steve Souders para receber conselhos), 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 receber conselhos sobre a otimização do TLS, consulte High Performance Browser Networking (em inglês) de Ilya Grigorik, além do OpenSSL Cookbook (em inglês) e Bulletproof SSL And TLS (em inglês) de Ivan Ristic.

Em alguns casos, o TLS pode melhorar o desempenho, principalmente por permitir o HTTP/2. Para mais informações, consulte a palestra de Chris Palmer sobre desempenho HTTPS e HTTP/2 no Chrome Dev Summit 2014.

Cabeçalhos de referência

Quando os usuários clicam em links do seu site HTTPS para outros sites HTTP, os agentes do usuário 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 o 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 vários problemas com cabeçalhos de referenciador, use o novo padrão de política de referenciador.

Receita de anúncios

Os operadores de sites que geram receita com a veiculaçã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 preocupações com a segurança do conteúdo misto, um <iframe> HTTP não funciona em uma página HTTPS. Até que os anunciantes publiquem por HTTPS, os operadores de site não podem migrar para HTTPS sem perder a receita de anúncios. No entanto, até que os operadores de site migrem para HTTPS, os anunciantes têm pouca motivação para publicar HTTPS.

Para começar a resolver esse impasse, use anunciantes que ofereçam serviços de anúncios por HTTPS e peça aos anunciantes que não veiculam HTTPS para que pelo menos ofereçam essa opção. Talvez seja necessário adiar a conclusão de Fazer URLs intrasite relativos até que um número suficiente de anunciantes interaja corretamente.