CDN:Perguntas frequentes sobre HTTPS

Os principais tipos de ataques HTTP são:

• Injeção de SQL: invasores exploram aplicações existentes para injetar comandos SQL maliciosos nos mecanismos de banco de dados de back-end e executá-los. Eles também podem 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 o projetista planejou.

• Cross-site scripting: o cross-site scripting (XSS) é um dos métodos mais comuns e básicos para atacar sites. Invasores publicam dados que contêm código malicioso em páginas da web. Quando um usuário visualiza 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: a falsificação de solicitação entre sites (CSRF) é outro ataque comum. Invasores forjam solicitações de várias maneiras para imitar o comportamento de usuários que enviam formulários, com o objetivo de adulterar dados do usuário ou executar tarefas específicas. Para se passar por um usuário, os ataques CSRF e XSS geralmente atuam em conjunto, mas os invasores também podem usar outros meios, como enganar os usuários para que cliquem 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, há 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, todas as operações de redirecionamento devem ser validadas para evitar o redirecionamento para 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. Uma segunda solução são os tokens de redirecionamento: anexe um token às URLs legítimas e valide o token no momento do redirecionamento.

Quando o HTTPS é ativado na origem, o consumo de recursos de computação aumenta em comparação com o acesso HTTP à origem. Esse aumento vem principalmente da criptografia e descriptografia assimétrica durante o handshake HTTPS, e o consumo de recursos cresce significativamente sob alta simultaneidade. O consumo de criptografia e descriptografia simétrica é basicamente o mesmo do HTTP, portanto, a taxa de reutilização de sessão deve ser aumentada. No entanto, acessar a origem diretamente por HTTPS leva mais tempo do que acessar a origem diretamente por HTTP. Para conteúdo estático, a distribuição de borda reduz o tempo de transmissão ao custo de um tempo extra de handshake, de modo que o tempo geral de acesso diminui. Além disso, os recursos estáticos não precisam ser buscados na origem, o que reduz as interações com a origem e diminui o consumo de recursos nela.

Não. Você precisa analisar isso pelos seguintes aspectos:

• Segurança: se algumas páginas forem HTTP e outras forem HTTPS, quando outros recursos (como arquivos JS ou CSS) forem carregados por 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 evitar esse risco.

• Desempenho: quando um site oferece suporte a HTTPS e HTTP, a alternância entre os dois protocolos exige muitos redirecionamentos no lado do servidor. Quando esses redirecionamentos são acionados, o carregamento da página fica mais lento.

• Ecossistema web: os navegadores oferecem um suporte mais favorável ao HTTPS, e os mecanismos de busca fornecem um melhor suporte de indexação para sites HTTPS.

O HTTPS é a interação entre o cliente e o servidor. Antes do uso da CDN, o cliente interage diretamente com a origem, portanto, o HTTPS deve ser configurado na origem. Após o uso da CDN, o cliente interage com a CDN. Se você quiser acessar a CDN por HTTPS, deverá configurar um certificado HTTPS na CDN. Para obter informações sobre como configurar um certificado HTTPS na CDN, consulte Configure an HTTPS certificate.

Não. O certificado HTTPS no servidor de origem e o certificado HTTPS na CDN existem de forma independente. A atualização do certificado na origem não afeta o certificado HTTPS na CDN. Você só precisa atualizar o certificado HTTPS na CDN quando o certificado configurado na CDN estiver prestes a expirar ou já tiver expirado. Para mais informações, consulte Configure an HTTPS certificate.

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

1. A configuração de 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 de forma independente 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 configuração de um certificado na borda.

1. Quando o protocolo de origem é definido para seguir, ele é afetado pelo protocolo de acesso do cliente

   • Após a configuração de um certificado HTTPS e a ativação da aceleração segura HTTPS, a CDN oferece suporte a acesso por HTTP e HTTPS;

   • Se o protocolo de origem for definido para seguir o cliente: quando o cliente acessa a CDN por HTTP, a CDN busca conteúdo na origem pela porta 80; quando o cliente acessa a CDN por HTTPS, a CDN busca conteúdo na origem pela porta 443.

2. Se a criptografia HTTPS de link completo for necessária

   • Configurar apenas um certificado de borda não é suficiente. Você também deve definir o protocolo de origem como HTTPS nas configurações de origem e garantir que a origem ofereça suporte ao acesso HTTPS.

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

Você não pode solicitar um certificado HTTPS gratuito para um nome de domínio curinga, como *.aliyundoc.com, no console do Alibaba Cloud CDN. Adquira um certificado SSL curinga no Certificate Management Service. Para mais informações, consulte What kind of domain names are supported by wildcard domain certificates?.

Após adquirir o certificado, configure o certificado HTTPS no console do Alibaba Cloud CDN e defina Certificate Source como Certificate Management Service. Para mais informações, consulte Configure an SSL certificate.

Os arquivos de certificado emitidos por uma autoridade certificadora intermediária contêm vários certificados. Você deve concatenar o certificado do servidor e os certificados intermediários em um único certificado completo. Em seguida, insira esse certificado no console para 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 as instruções correspondentes ao emitir o certificado. Siga as instruções.

O certificado concatenado é o seguinte.

-----BEGIN CERTIFICATE-----
MIIE/DCCA+SgAwIBAgIUOWvvEj41j5OamNabjVbGY42BBcQwDQYJKoZIhvcNAQEL
BQAwgYIxCzAJBgNVBAYTAnNuMRIwEAYDVQQIDALHdWFuZORvbmcxETAPBgNVBAcM
CFNgZWS6aGVuMQ8wDQYDVQQKDAZIdWF3ZWkxCzAJBgNVBAsMAklMS4wLAYDVQQD
DCVIdWF3ZWkgV2ViIFN1Y3VyaXR5IEJOQ1NBIFJvb3QgQ0EgVjMxCzAJBgNVBAYT
ODAwNDAO1oXDTE4MTAxODAwNDAO1owGZoxCzAJBgNVBAYTAkNOMRAwDgYDVQQI
DAdqeWFuZ3N1M1MRAwDgYDVQQHDAdUYW5qeWFuZzELMAkGA1UECgwCVzGxGzAYBgNVBAsMEVdl
dHdhcmVGVjG5bG93Z2oxCzAJBgNVBAYTAkNOMRAwDgYDVQQIDAd5dWEwZ3N1M9
9wOBAAEFAOCAQ8AMIIBCgKCAQEA1hC5fG6J2OX5F/YW7bo6130yzgaWVGLEX8t
1dQ1JAus93xMC2Jr6UOXmXR6WaRu51ZxpPfLT/IV6UnvMLnxJQBavqeUykCSkadW
stYA9ttTI/FYq+MR1XKbNzqK/ADhRfmR4ovS/3w1wxvdpwySfR2+V/D6TjxHZCjc
+81SmUuLxsgoUe79B/ruccY1ufuqr3v0TToaNn4c37kwjJeKf+b2F/IqO/KF+9zF
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBIGA1UdEQQ7MDmCE3d3dy5odWF3ZW1j
bG91ZC5jb22CESouaHVhd2VpY2xvdWQuY29tgg9odWF3ZW1jbG91ZC5jb20wDQYJ
KoZIhvcNAQELBQADggEBAcsLP7Hj+4KY1ES38On0UuvQ3st8axvhDD9jZGoninzW
JSGpdm04NEsh1vwSFdEHpjy/xKSLCIqg5Ue8tTI8zoF13U0R0nMeHSKsxJG6zc8X
h/3N217oBygFgvpmc6YX66kvuXmkA7KRniiYS0nmCi2KUyngSBv4dsk21dj1lqQ3b
HI+1o26Q9odLsmhsKOsFUC0vDKoMIJz0Socy7Cq1+tFWF9S79MI4QjxaXEVvpIEg
QLEze3BXSsoiWRkdfasdDB9s+UtdWeJyOHMh/otvUQCtB6areV2+CPthmDENA+A8
IK6GzHyp/mgrzwKdDh97aQ42ARreAv4KVFAiJGZO2LOY=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID2TCCAsSgAwIBAgIJALQPO9xFFzmA0GCSqGSIb3DQEBCwUAMIGCMQswCQYD
VQQGEwJjbjESMBAGA1UECAwJR3Vhbm1dEb2SnMREwDwYDVQQHDAhTaGVuemhlbjEP
MA0GA1UECgwGSHVhd2VpMQswCQYDVQQLDAJJVDEuMCwGA1UEAwwlSHVhd2VpIFdl
YiBTZWN1cmUgSW50ZXJuZXQgR2F0ZXdheSBDQSBWMzELMAkGA1UEBhMCQ04xEjAQ
BgNVBAgMCUd1YW5nZG9uZzERMA8GA1UEBwwIU2hlbnpoZW4xDzANBgNVBAoMBkh1
YWdlaTELMAkGA1UECwwCSVQxLjAsBgNVBAMMJUh1YXdlaSBXZWIgU2VjdXJpdHkg
RUJDU0EgUm9vdCBDQSBWMzELMAkGA1UEBhMCQ04wHhcNMTgxMDE4MDAwMDAwWhcN
MREwDwYDVQQHDAhTaGVuemhlbjEPMA0GA1UECgwGSHVhd2VpMQswCQYDVQQLDAJJ
VDEuMCwGA1UEAwwlSHVhd2VpIFdlYiBTZWN1cmUgSW50ZXJuZXQgR2F0ZXdheSBD
QSBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL
IwQYMBaFDB6DZZX4Am+isCoa48e42drAXpsMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQELBQADggEBAKN9k5jRX56jw2Ku5Mn3gZu/kQQw+mLkIuJEeDwS6LMjWOHv
313x1v/Uxv4hQmo6OXqg2OM4dfIJoVVKgiLlBCpXv0/X600rq3UPediEMaXkmM+F
tuJnoPCXmew7QvvQQwis+0xmhpRPgON6xIK01vIbAV69TkpwJW3duj1FuRgSvn
Rab4gVi14x+bUgTbGHCvDH99PhAdvXOuI1mk5Kb/JhCNbhRAHezyfLrvimxI0Ky
2KWZitN+M1UWvSYG8j3mtDm+/FuA93V1yEzRjKj92egCgM1u671liddt7zzzzqW+U
QLUOevUmUHQsV5mk62v1e8sRViHB1B2HJ3DU5gE=
-----END CERTIFICATE-----

Você não precisa ativar o HSTS nos subdomínios. Após ativar Include Subdomains, a política HSTS entra em vigor em todos os subdomínios. Certifique-se de que você ative o acesso HTTPS normal em cada subdomínio. Caso contrário, o subdomínio ficará inacessível.

O fato de um cliente acessar o site por HTTP ou HTTPS é inteiramente um comportamento do cliente. Se você quiser forçar os clientes a usar o acesso HTTPS, poderá ativar o redirecionamento forçado de HTTPS na CDN. Para mais informações, consulte Configure HTTP/S redirection.

Isso ocorre principalmente porque a CDN depende do SNI ao processar solicitações HTTPS. O SNI é uma extensão do protocolo TLS que permite que um cliente especifique 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 oferecer suporte ao SNI, ou podem não enviar informações de 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:

• Sistema do cliente: atualize os sistemas operacionais e os softwares em uso para que haja suporte ao SNI.

• Atualize o firmware do dispositivo IoT: para dispositivos IoT, verifique e instale regularmente as atualizações de firmware mais recentes fornecidas pelo fabricante.

Sim. A ativação da aceleração HTTPS na CDN ativa, na verdade, 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, porque o link entre os nós de borda da CDN e a sua origem ainda usa o protocolo HTTP e não adiciona carga extra à sua origem.

Se você adquirir diferentes tipos de certificados, serão necessárias taxas extras. Você também pode fazer login no console do Certificate Management Service para solicitar um certificado de teste (edição gratuita), que é um certificado de nível DV. Você pode 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 para esse nome de domínio. Para obter informações sobre as cobranças de solicitações HTTPS estáticas, consulte Static HTTPS requests.

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, a solicitação é respondida corretamente, portanto, é contada como uma solicitação HTTPS. Como essa solicitação não transporta nenhum conteúdo de recurso, o tráfego faturado é muito pequeno.