SSL/TLS na CDN | Segurança da CDN

Quais são os riscos de segurança enfrentados por uma CDN?

Como todas as redes expostas à internet, as CDNs precisam se proteger contra ataques on-path, invasões de dados e tentativas de sobrecarregar a rede do servidor de origem visado usando ataques de DDoS. Uma CDN pode adotar diversas estratégias para mitigar vulnerabilidades, incluindo uma criptografia SSL/TLS adequada e hardwares de criptografia especializados.

O que é criptografia SSL/TLS?

A Segurança da Camada de Transporte (TLS) é um protocolo para criptografar os dados enviados pela internet. O TLS foi desenvolvido a partir da Camada de Soquete Seguro (SSL), o primeiro protocolo de criptografia na web amplamente adotado, para corrigir a maioria das falhas de segurança do protocolo anterior. Por razões históricas, o setor ainda usa ambos os termos de forma relativamente intercambiável. Qualquer site que você acesse cujo endereço comece com https://, ao invés de http://, está usando TLS/SSL para a comunicação entre um navegador e um servidor.

Quando se trata de evitar que os invasores acessem dados importantes, as práticas de criptografia adequadas são uma necessidade. Como a internet foi projetada de forma a transferir dados entre vários locais, os pacotes contendo informações importantes podem ser interceptados à medida que se deslocam ao redor do mundo. Com o uso de um protocolo de criptografia, os intermediários ficam impedidos de decodificar o conteúdo dos dados transferidos e apenas o destinatário pretendido consegue decodificar e ler as informações.

O protocolo TLS foi projetado para fornecer três componentes:

1. Autenticação: capacidade de verificar a validade das identificações fornecidas
2. Criptografia: capacidade de ocultar as informações enviadas de um host para outro
3. Integridade: capacidade de detectar falsificação e adulteração

Saiba mais sobre o SSL/TLS gratuito da Cloudflare.

O que é certificado SSL?

Para habilitar o TLS, um site precisa de um certificado SSL e de uma chave correspondente. Os certificados são arquivos que contêm informações sobre o proprietário de um site e a metade pública de um par de chaves assimétricas. Uma autoridade de certificação (CA) assina o certificado digitalmente para confirmar que as informações do certificado estão corretas. Ao confiar no certificado, você confia no fato de que a autoridade de certificação cumpriu sua obrigação de verificar.

Os sistemas operacionais e navegadores costumam usar uma lista de autoridades de certificação nas quais confiam implicitamente. Quando um site apresenta um certificado assinado por uma autoridade de certificação não confiável, o navegador alerta o visitante de que algo pode estar sendo tramado.

Os certificados e a forma como são implementados também podem ser classificados de forma independente com base em sua força, na compatibilidade com protocolos e outras características. As classificações podem mudar ao longo do tempo, à medida que implementações melhores e mais recentes se tornam disponíveis ou outros fatores resultam na redução da segurança total de uma implementação de certificado. Se tiver uma implementação de segurança SSL mais antiga com uma classificação inferior, um servidor de origem geralmente receberá uma avaliação pior, poderá se mostrar vulnerável e se tornar comprometido.

Uma CDN tem a vantagem adicional de fornecer segurança aos visitantes dos ativos hospedados em sua rede com o uso de um certificado fornecido pela CDN. Como os visitantes se conectam apenas à CDN, o uso de um certificado mais antigo ou menos seguro entre o servidor de origem e a CDN não irá afetar a experiência do cliente.

Realisticamente falando, uma segurança mais fraca entre o servidor e a borda continua representando uma vulnerabilidade e deve ser evitada, especialmente se levarmos em conta a facilidade com que é possível atualizar a segurança de um servidor de origem usando uma criptografia de origem gratuita.

Uma segurança adequada também é importante para a pesquisa orgânica: propriedades da web criptografadas recebem uma melhor classificação na pesquisa do Google.

O funcionamento de uma conexão SSL/TLS é diferente do de uma conexão TCP/IP tradicional. Após os estágios iniciais da conexão TCP, ocorre uma troca separada para configurar a conexão segura. Para fins deste artigo, o dispositivo que solicita a conexão segura será definido como o cliente e o dispositivo que fornece a conexão segura como o servidor, como ocorre quando um usuário carrega uma página web criptografada com SSL/TLS.

Em primeiro lugar temos o handshake TCP/IP feito em três etapas:

1. O cliente envia ao servidor um pacote SYN para iniciar a conexão.
2. Em seguida, o servidor responde ao pacote inicial com um pacote SYN/ACK para confirmar a comunicação.
3. Finalmente, o cliente devolve um pacote ACK para confirmar o recebimento do pacote do servidor. Após concluir essa sequência de envios e recebimentos de pacotes, a conexão TCP é aberta e consegue enviar e receber dados.

Após o handshake TCP/IP ter sido efetuado, tem início o handshake da criptografia TLS. Os processos detalhados por trás da implementação de um handshake TLS estão além do escopo deste guia. Ao invés de abordá-los, vamos nos concentrar no objetivo principal do handshake e no tempo necessário para concluir o processo.

Sob um ponto de vista de alto nível, um handshake TLS tem três componentes principais:

1. O cliente e o servidor negociam as versões do TLS e o tipo de cifra de criptografia que será usada na comunicação.
2. O cliente e o servidor tomam providências para garantir uma comunicação mutuamente autêntica.
3. Uma chave é trocada para ser usada em comunicações criptografadas futuras.

O diagrama abaixo mostra cada uma das etapas envolvidas em um handshake TCP/IP e um handshake TLS. Tenha em mente que cada seta representa uma comunicação separada que precisa viajar fisicamente entre o cliente e o servidor. Já que o número total de mensagens sendo trocadas entre eles aumenta com o uso da criptografia TLS, há também um aumento nos tempos de carregamento da página web.

Para fins de ilustração, podemos dizer que o handshake TCP leva cerca de 50 ms, enquanto o handshake TLS leva cerca de 110 ms. Isso decorre, em grande parte, do tempo necessário para que os dados trocados entre o cliente e o servidor sejam enviados nas duas direções. O conceito de tempo de ida e volta (RTT), que é o tempo necessário para que as informações sejam enviadas de um dispositivo a outro e de volta ao dispositivo de origem, pode ser usado para quantificar o “preço” para se criar uma conexão. Caso não seja otimizado e não use uma CDN, o RTT adicional representará um aumento da latência e do tempo de carregamento para os usuários finais. Felizmente, existem otimizações que podem ser feitas para reduzir o tempo de carregamento total e o número de viagens de ida e volta entre os dispositivos.

Como podemos reduzir a latência do SSL?

As otimizações do SSL podem reduzir o RTT e diminuir o tempo de carregamento da página. Veja três maneiras pelas quais uma conexão TLS pode ser otimizada:

Retomada da sessão TLS: uma CDN pode manter a conexão entre o servidor de origem e a rede CDN ativa por mais tempo ao retomar a mesma sessão para solicitações adicionais. Manter a conexão ativa economiza o tempo gasto para renegociar a conexão entre a CDN e o servidor de origem quando o cliente solicita à origem o resgate de um conteúdo não armazenado em cache. Na medida em que o servidor de origem receber solicitações adicionais enquanto a conexão com a CDN for mantida, os visitantes adicionais do site sofrerão menos latência.

O custo total da retomada de uma sessão é menos de 50% do custo de um handshake TLS completo, principalmente porque a retomada da sessão requer apenas uma viagem de ida e volta, enquanto um handshake TLS completo requer duas. Além disso, uma retomada de sessão não requer nenhuma grande aritmética de campo finito (ao contrário de novas sessões), de modo que o custo de CPU para o cliente é quase desprezível se comparado ao de um handshake TLS completo. Para os usuários de dispositivos móveis, o aumento do desempenho obtido com a retomada da sessão significa uma experiência de navegação muito mais reativa e favorável à vida útil da bateria.

Habilitar um Falso Início de TLS: quando um visitante estiver visualizando o site pela primeira vez, a retomada da sessão mencionada acima não irá ajudar. Um Falso Início de TLS (TLS False Start) permite que o remetente envie dados do aplicativo sem um handshake TLS completo.

O Falso Início não modifica o protocolo TLS propriamente dito: modifica apenas o momento em que os dados são transferidos. Assim que o cliente dá início à troca de chaves, a criptografia fica garantida e a transferência de dados pode começar. Essa mudança reduz o número total de viagens de ida e volta, reduzindo em 60 ms a latência necessária.

Tempo zero de retomada da viagem de ida e volta (0-RTT): o 0-RTT permite a retomada da sessão sem adicionar uma latência de RTT extra à conexão. As conexões retomadas usando TLS 1.3 e 0-RTT proporcionam um aumento na velocidade de conexão que resulta em uma experiência na web mais rápida e mais tranquila para os usuários, no caso de sites que são visitados regularmente. Esse aumento de velocidade é particularmente percebido nas redes móveis.

O 0-RTT representa um aprimoramento eficaz, mas sem abrir mão de um certo nível de segurança. Para superar o risco daquilo que conhecemos como um ataque de repetição, um serviço de CDN pode implementar restrições no tipo de solicitações HTTP e nos parâmetros permitidos. Para saber mais, confira essa apresentação do 0-RTT.

Proteção da CDN contra ataques DDoS

Uma das mais substanciais vulnerabilidades de segurança das propriedades da web na internet moderna é o uso de ataques de negação de serviço distribuída (DDoS). Ao longo do tempo, esses ataques de DDoS aumentaram de tamanho e de complexidade, com os invasores utilizando botnets para direcionar o tráfego de ataques aos sites visados. Uma grande CDN corretamente configurada oferece a vantagem em potencial da escala como um fator de proteção contra DDoS: por ter locais de data center suficientes e recursos consideráveis de largura de banda, a CDN é capaz de resistir e mitigar uma quantidade de tráfego de ataque de entrada que facilmente sobrecarregaria o servidor de origem visado.

Existem outras medidas que podem ser adotadas para proteger uma conexão TLS. Saiba mais sobre a CDN da Cloudflare e sobre como se manter à frente dos ataques de TLS. Visite a Central de Diagnósticos da Cloudflare para verificar se o seu site está usando HTTPS corretamente.