FAQ sobre configuração e uso de aceleração HTTPS - CDN: Central de Documentação do Alibaba Cloud

O HTTPS é um canal HTTP projetado para segurança, oferecendo maior proteção na transmissão de conteúdo pela CDN. Além de garantir acesso rápido ao conteúdo, os clientes podem navegar no site com mais segurança e eficiência. Este tópico responde às perguntas mais frequentes sobre HTTPS.

Fundamentos e princípios do HTTPS

Quais são os tipos comuns de ataques HTTP?

Os tipos mais comuns de ataques HTTP incluem:

Injeção de SQL: invasores exploram aplicações existentes para injetar comandos SQL maliciosos nos mecanismos de banco de dados back-end e executá-los. Também é possível inserir instruções SQL maliciosas em formulários web para obter o banco de dados de um site com vulnerabilidades de segurança, em vez de executar as instruções SQL conforme planejado pelo desenvolvedor.
Cross-site scripting: o cross-site scripting (XSS) é um dos métodos mais comuns e básicos para atacar sites. Invasores publicam dados contendo código malicioso em páginas da web. Quando um usuário visualize essa página, o script específico é executado com a identidade e as permissões do usuário que está navegando. O XSS facilita a adulteração de dados e o roubo de informações do usuário.
Cross-site request forgery: o cross-site request forgery (CSRF) é outro ataque comum. Invasores forjam solicitações de várias maneiras para simular o comportamento de usuários que enviam formulários, com o objetivo de adulterar dados ou executar tarefas específicas. Para se passar por um usuário, ataques CSRF e XSS geralmente funcionam em conjunto, mas os invasores também podem usar outros meios, como induzir usuários a clicar em um link malicioso.
Ataque a cabeçalhos HTTP: ao usar um navegador para visualizar qualquer site, independentemente das tecnologias e frameworks utilizados, o protocolo HTTP está envolvido. No protocolo HTTP, existe uma linha em branco entre o cabeçalho de resposta e o conteúdo, ou seja, dois conjuntos de caracteres CRLF (0x0D 0x0A). Essa linha em branco marca o fim dos cabeçalhos e o início do conteúdo, e os invasores podem explorar isso. Basta que os invasores encontrem uma maneira de injetar caracteres arbitrários nos cabeçalhos para que esse ataque ocorra.
Ataque de redirecionamento: um ataque muito utilizado é o phishing. Invasores que praticam phishing geralmente enviam às vítimas um link com aparência legítima. Quando as vítimas acessam o link, são redirecionadas para um site malicioso, permitindo que os invasores ganhem sua confiança e roubem suas informações. Para evitar isso, valide todas as operações de redirecionamento para impedir o direcionamento a destinos perigosos. Uma solução comum é a lista de permissões: adicione URLs de redirecionamento legítimas à lista de permissões e rejeite redirecionamentos para domínios que não estejam nela. Outra solução são os tokens de redirecionamento: anexe um token a URLs legítimas e valide-o durante o redirecionamento.

Ativar a aceleração HTTPS consome mais recursos ou reduz a velocidade de acesso?

Quando o HTTPS é ativado na origem, o consumo de recursos computacionais aumenta em comparação com o acesso HTTP à origem. Esse aumento vem principalmente da criptografia e descriptografia assimétricas durante o handshake HTTPS, e o consumo de recursos cresce significativamente sob alta concorrência. O consumo de criptografia e descriptografia simétricas é basicamente o mesmo que no HTTP; portanto, aumente a taxa de reutilização de sessão. No entanto, acessar a origem diretamente via HTTPS leva mais tempo do que acessar a origem diretamente via HTTP. Para conteúdo estático, a distribuição na borda reduz o tempo de transmissão ao custo de um tempo extra de handshake, de modo que o tempo total de acesso diminui. Além disso, recursos estáticos não precisam ser buscados na origem, o que reduz as interações com ela e diminui o consumo de recursos no servidor de origem.

Cenários de uso e decisões sobre HTTPS

O HTTPS é necessário apenas para login no site?

Não. Analise essa questão pelos seguintes aspectos:

Segurança: se algumas páginas forem HTTP e outras HTTPS, quando outros recursos (como arquivos JS ou CSS) forem carregados via HTTP ou por meio de um service de CDN inseguro, o site ainda enfrentará o risco de expor informações do usuário. O HTTPS em todo o site é a maneira mais simples de prevenir esse risco.
Desempenho: quando um site suporta tanto HTTPS quanto HTTP, alternar entre os dois protocolos exige muitos redirecionamentos no lado do servidor e, quando esses redirecionamentos são acionados, o carregamento da página fica mais lento.
Ecossistema web: os navegadores oferecem suporte mais favorável ao HTTPS, e os mecanismos de busca fornecem melhor indexação para sites HTTPS.

O HTTPS já está configurado na origem. Ainda preciso configure o HTTPS na CDN?

O HTTPS representa a interação entre o cliente e o servidor. Antes do uso da CDN, o cliente interage diretamente com a origem; portanto, configure o HTTPS na origem. Após o uso da CDN, o cliente passa a interagir com a CDN. Se você deseja acessar a CDN via HTTPS, configure um certificado HTTPS na CDN. Para obter informações sobre como configurar um certificado HTTPS na CDN, consulte Configure an HTTPS certificate.

O certificado HTTPS na origem foi atualizado. O certificado na CDN também precisa ser atualizado?

Não. O certificado HTTPS no servidor de origem e o certificado HTTPS na CDN existem de forma independente. Atualizar o certificado na origem não afeta o certificado HTTPS na CDN. Atualize o certificado HTTPS na CDN apenas quando o certificado configurado nela estiver prestes a expirar ou já tiver expirado. Para mais informações, consulte Configure an HTTPS certificate.

A porta de origem muda após a configuração de um certificado HTTPS?

Configurar um certificado HTTPS para um nome de domínio acelerado não afeta diretamente a porta de origem, mas a afeta indiretamente no modo de acompanhamento de protocolo. As regras específicas são as seguintes:

Configurar um certificado HTTPS em si não tem relação com a porta de origem

O certificado HTTPS fornece apenas criptografia entre o cliente e os nós da CDN. Ele não altera o protocolo ou a porta de origem entre a CDN e a origem. O comportamento da origem é controlado independentemente pela configuração do protocolo de origem: quando definido como HTTP, a CDN busca conteúdo na origem pela porta 80 por padrão; quando definido como HTTPS, a CDN busca conteúdo na origem pela porta 443 por padrão. Isso não tem relação com a existência de um certificado configurado na borda.

Quando o protocolo de origem está definido como seguir, ele é afetado pelo protocolo de acesso do cliente
- Após configurar um certificado HTTPS e ativar a aceleração segura HTTPS, a CDN suporta acesso tanto por HTTP quanto por HTTPS;
- Se o protocolo de origem estiver definido para seguir o cliente: quando o cliente acessa a CDN via HTTP, a CDN busca conteúdo na origem pela porta 80; quando o cliente acessa a CDN via HTTPS, a CDN busca conteúdo na origem pela porta 443.
Se for necessária criptografia HTTPS em todo o link
- Configurar apenas um certificado de borda não é suficiente. Defina também o protocolo de origem como HTTPS nas configurações de origem e certifique-se de que a origem suporte acesso HTTPS.

Para obter informações sobre como configurar o protocolo de origem, consulte Configure the origin protocol policy.

Configuração e upload de certificados

Ao fazer upload de um certificado de terceiros que contém vários arquivos .crt, como devo proceder?

Arquivos de certificado emitidos por uma autoridade certificadora intermediária contêm múltiplos certificados. Concatene o certificado do servidor e os certificados intermediários em um único certificado completo antes de fazer o upload.

Abra todos os arquivos de certificado no formato *.PEM com um editor de texto. Coloque o certificado do servidor primeiro, seguido pelos certificados intermediários. Não deve haver linhas em branco entre os certificados. Na maioria dos casos, a autoridade certificadora fornece instruções correspondentes ao emitir o certificado. Siga essas instruções.

O certificado concatenado fica da seguinte forma:

Comportamento de acesso e compatibilidade do HTTPS

Ao configurar o HSTS, após ativar include subdomains, preciso ativar o HSTS nos subdomínios?

Não é necessário ativar o HSTS nos subdomínios. Depois que você ativa Include Subdomains, a política HSTS entra em vigor para todos os subdomínios. Certifique-se de que cada subdomínio suporte acesso HTTPS normal. Caso contrário, o subdomínio ficará inacessível.

O HTTPS já está configurado. Por que os clientes ainda acessam o site via HTTP?

O fato de um cliente acessar o site via HTTP ou HTTPS depende inteiramente do comportamento do cliente. Para forçar os clientes a usar acesso HTTPS, ative o redirecionamento forçado HTTPS na CDN. Para mais informações, consulte Configure HTTP/S redirection.

Por que a maioria dos dispositivos consegue acessar um nome de domínio acelerado via HTTPS, enquanto alguns não conseguem?

Isso ocorre principalmente porque a CDN depende do SNI ao processar solicitações HTTPS. O SNI é uma extensão do protocolo TLS que permite ao cliente especificar o nome do host que deseja visitar ao iniciar uma solicitação de conexão HTTPS.

No entanto, alguns clientes mais antigos ou com configurações especiais (por exemplo, versões antigas do Android ou iOS, Java 6 e anteriores, e alguns dispositivos IoT) podem não suportar SNI ou não enviar informações SNI ao iniciar solicitações HTTPS. Nesse caso, os nós da CDN não conseguem determinar o site exato que o cliente deseja visitar e, portanto, não podem fornecer o certificado SSL/TLS correto. Como resultado, a tentativa de conexão HTTPS falha e os usuários não conseguem acessar o conteúdo do site.

Para melhorar essa situação, recomendamos as seguintes medidas:

Atualize o sistema do cliente: garanta que os sistemas operacionais e softwares em uso estejam atualizados para que haja suporte ao SNI.
Atualize o firmware de dispositivos IoT: para dispositivos IoT, verifique e instale regularmente as atualizações de firmware mais recentes fornecidas pelo fabricante.

Faturamento do HTTPS

Existem cobranças extras após ativar a aceleração HTTPS na CDN?

Sim. Ativar a aceleração HTTPS na CDN significa, na prática, ativar o HTTPS no link entre o cliente e os nós de borda da CDN. Como o handshake SSL e a descriptografia de conteúdo exigem computação, o consumo de recursos de CPU dos servidores da CDN aumenta. No entanto, o consumo de recursos no seu servidor de origem não aumenta, pois o link entre os nós de borda da CDN e sua origem ainda usa o protocolo HTTP e não adiciona carga extra à sua origem.

Se você adquirir diferentes tipos de certificados, taxas extras serão aplicadas. Você também pode fazer login no Certificate Management Service console para solicitar um certificado de teste (edição gratuita), que é um certificado de nível DV. É possível solicitar um certificado de teste para cada nome de domínio acelerado. O certificado é válido por três meses e pode ser renovado automaticamente de forma gratuita. Após configurar um certificado HTTPS, a CDN fatura todas as solicitações HTTPS desse nome de domínio. Para obter informações sobre as cobranças de solicitações HTTPS estáticas, consulte Billing of HTTPS requests for static content.

Quando as solicitações atingem a lista de bloqueios de IP ou a lista de bloqueios de User-Agent, ou quando retornam 403/404, as solicitações HTTPS são faturadas?

As solicitações HTTPS são faturadas. Quando uma solicitação atinge determinadas regras de política e retorna um código de status 403 ou 404, ela recebe uma resposta correta, sendo contabilizada como uma solicitação HTTPS. Como tal solicitação não transporta nenhum conteúdo de recurso, o tráfego faturado é muito pequeno.