TLS de ponta a ponta com o Azure Front Door

  • Artigo

Transport Layer Security (TLS), anteriormente conhecido como Secure Sockets Layer (SSL), é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor web e um cliente, como um navegador web. Esse link garante que todos os dados passados entre o servidor e o cliente permaneçam privados e criptografados.

Para atender aos seus requisitos de segurança ou conformidade, o Azure Front Door oferece suporte à criptografia TLS de ponta a ponta. O descarregamento TLS/SSL da Porta da Frente encerra a conexão TLS, descriptografa o tráfego na Porta da Frente do Azure e criptografa novamente o tráfego antes de encaminhá-lo para a origem. Quando as conexões com a origem usam o endereço IP público da origem, é uma boa prática de segurança configurar HTTPS como o protocolo de encaminhamento na sua Porta da Frente do Azure. Usando HTTPS como o protocolo de encaminhamento, você pode impor criptografia TLS de ponta a ponta para todo o processamento da solicitação do cliente até a origem. O descarregamento de TLS/SSL também é suportado se você implantar uma origem privada com o Azure Front Door Premium usando o recurso Private Link .

Este artigo explica como o Azure Front Door funciona com conexões TLS. Para obter mais informações sobre como usar certificados TLS com seus próprios domínios personalizados, consulte HTTPS para domínios personalizados. Para saber como configurar um certificado TLS em seu próprio domínio personalizado, consulte Configurar um domínio personalizado no Azure Front Door usando o portal do Azure.

Encriptação TLS ponto a ponto

O TLS de ponta a ponta permite proteger dados confidenciais enquanto estão em trânsito para a origem, enquanto se beneficiam dos recursos do Azure Front Door, como balanceamento de carga global e cache. Alguns dos recursos também incluem roteamento baseado em URL, divisão TCP, armazenamento em cache no ponto de presença mais próximo dos clientes e personalização de solicitações HTTP na borda.

O Azure Front Door descarrega as sessões TLS na borda e descriptografa as solicitações do cliente. Em seguida, ele aplica as regras de roteamento configuradas para rotear as solicitações para a origem apropriada no grupo de origem. Em seguida, o Azure Front Door inicia uma nova conexão TLS com a origem e criptografa novamente todos os dados usando o certificado da origem antes de transmitir a solicitação para a origem. Qualquer resposta da origem é criptografada através do mesmo processo de volta para o usuário final. Você pode configurar seu Azure Front Door para usar HTTPS como o protocolo de encaminhamento para habilitar o TLS de ponta a ponta.

Versões TLS suportadas

O Azure Front Door suporta quatro versões do protocolo TLS: TLS versões 1.0, 1.1, 1.2 e 1.3. Todos os perfis do Azure Front Door criados após setembro de 2019 usam o TLS 1.2 como o mínimo padrão com o TLS 1.3 habilitado, mas o TLS 1.0 e o TLS 1.1 ainda têm suporte para compatibilidade com versões anteriores.

Embora o Azure Front Door ofereça suporte ao TLS 1.2, que introduziu a autenticação cliente/mútua no RFC 5246, atualmente, o Azure Front Door ainda não oferece suporte à autenticação cliente/mútua (mTLS).

Você pode configurar a versão mínima do TLS no Azure Front Door nas configurações HTTPS de domínio personalizado usando o portal do Azure ou a API REST do Azure. Atualmente, você pode escolher entre 1.0 e 1.2. Como tal, especificar TLS 1.2 como a versão mínima controla a versão TLS mínima aceitável que o Azure Front Door aceitará de um cliente. Para a versão mínima do TLS 1.2, a negociação tentará estabelecer o TLS 1.3 e, em seguida, o TLS 1.2, enquanto para o TLS mínimo versão 1.0 todas as quatro versões serão tentadas. Quando o Azure Front Door inicia o tráfego TLS para a origem, ele tentará negociar a melhor versão do TLS que a origem pode aceitar de forma confiável e consistente. As versões TLS suportadas para conexões de origem são TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3.

Nota

  • Os clientes com TLS 1.3 habilitado são obrigados a dar suporte a uma das curvas EC compatíveis com Microsoft SDL, incluindo Secp384r1, Secp256r1 e Secp521, para fazer solicitações com êxito com o Azure Front Door usando TLS 1.3.
  • Recomenda-se que os clientes usem uma dessas curvas como sua curva preferida durante as solicitações para evitar o aumento da latência do handshake TLS, que pode resultar de várias viagens de ida e volta para negociar a curva EC suportada.

Certificados suportados

Ao criar seu certificado TLS/SSL, você deve criar uma cadeia de certificados completa com uma Autoridade de Certificação (CA) permitida que faz parte da Lista de CAs Confiáveis da Microsoft. Se utilizar uma AC não permitida, o pedido será rejeitado.

Não são permitidos certificados de ACs internas ou certificados autoassinados.

Grampeamento do Protocolo de Status de Certificado Online (OCSP)

O grampeamento OCSP é suportado por padrão no Azure Front Door e nenhuma configuração é necessária.

Conexão TLS de origem (Azure Front Door to origin)

Para conexões HTTPS, o Azure Front Door espera que sua origem apresente um certificado de uma autoridade de certificação (CA) válida com um nome de entidade correspondente ao nome de host de origem. Por exemplo, se seu nome de host de origem estiver definido como myapp-centralus.contosonews.net e o certificado que sua origem apresenta durante o handshake TLS não tiver myapp-centralus.contosonews.net ou *.contosonews.net no nome do assunto, o Azure Front Door recusará a conexão e o cliente verá um erro.

Nota

O certificado deve ter uma cadeia de certificados completa com certificados de folha e intermediários. A autoridade de certificação raiz deve fazer parte da lista de autoridades de certificação confiáveis da Microsoft. Se for apresentado um certificado sem cadeia completa, não é garantido que os pedidos que envolvem esse certificado funcionem como esperado.

Em certos casos de uso, como para testes, como uma solução alternativa para resolver a falha na conexão HTTPS, você pode desabilitar a verificação do nome do assunto do certificado para sua Porta da Frente do Azure. Observe que a origem ainda precisa apresentar um certificado com uma cadeia confiável válida, mas não precisa corresponder ao nome do host de origem.

No Azure Front Door Standard e Premium, você pode configurar uma origem para desabilitar a verificação do nome do assunto do certificado.

No Azure Front Door (clássico), você pode desabilitar a verificação do nome do assunto do certificado alterando as configurações do Azure Front Door no portal do Azure. Você também pode configurar a verificação usando as configurações do pool de back-end nas APIs do Azure Front Door.

Nota

Do ponto de vista da segurança, a Microsoft não recomenda desativar a verificação do nome do assunto do certificado.

Conexão TLS Frontend (cliente para Azure Front Door)

Para habilitar o protocolo HTTPS para entrega segura de conteúdo em um domínio personalizado do Azure Front Door, você pode optar por usar um certificado gerenciado pelo Azure Front Door ou usar seu próprio certificado.

Para obter mais informações, consulte HTTPS para domínios personalizados.

O certificado gerenciado do Azure Front Door fornece um certificado TLS/SSL padrão via DigiCert e é armazenado no Cofre da Chave do Azure Front Door.

Se você optar por usar seu próprio certificado, poderá integrar um certificado de uma CA suportada que pode ser um TLS padrão, um certificado de validação estendida ou até mesmo um certificado curinga. Não há suporte para certificados autoassinados. Saiba como habilitar HTTPS para um domínio personalizado.

Autorotação de certificados

Para a opção de certificado gerenciado do Azure Front Door, os certificados são gerenciados e girados automaticamente dentro de 90 dias do tempo de expiração pelo Azure Front Door. Para a opção de certificado gerenciado do Azure Front Door Standard/Premium, os certificados são gerenciados e girados automaticamente dentro de 45 dias após o tempo de expiração pelo Azure Front Door. Se você estiver usando um certificado gerenciado do Azure Front Door e vir que a data de expiração do certificado está a menos de 60 dias ou 30 dias para o SKU Standard/Premium, registre um tíquete de suporte.

Para o seu próprio certificado TLS/SSL personalizado:

  1. Você define a versão secreta como 'Mais recente' para que o certificado seja automaticamente girado para a versão mais recente quando uma versão mais recente do certificado estiver disponível no cofre de chaves. Para certificados personalizados, o certificado é girado automaticamente dentro de 3-4 dias com uma versão mais recente do certificado, independentemente do tempo expirado do certificado.

  2. Se uma versão específica for selecionada, a rotação automática não será suportada. Você terá que selecionar novamente a nova versão manualmente para girar o certificado. Leva até 24 horas para que a nova versão do certificado/segredo seja implantada.

    Nota

    Os certificados gerenciados do Azure Front Door (Standard e Premium) são alternados automaticamente se o registro CNAME do domínio apontar diretamente para um ponto de extremidade do Front Door ou apontar indiretamente para um ponto de extremidade do Gerenciador de Tráfego. Caso contrário, você precisará revalidar a propriedade do domínio para alternar os certificados.

    Você precisará garantir que a entidade de serviço do Front Door tenha acesso ao cofre das chaves. Consulte como conceder acesso ao seu cofre de chaves. A operação de distribuição de certificado atualizada pelo Azure Front Door não causará nenhum tempo de inatividade de produção, desde que o nome da entidade ou o nome alternativo da entidade (SAN) do certificado não tenha sido alterado.

Pacotes de codificação suportados

Para TLS 1.2/1.3 os seguintes pacotes de codificação são suportados:

  • TLS_AES_256_GCM_SHA384 (apenas TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (apenas TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Nota

Para o Windows 10 e versões posteriores, recomendamos ativar um ou ambos os pacotes de codificação ECDHE_GCM para maior segurança. O Windows 8.1, 8 e 7 não são compatíveis com esses pacotes de codificação ECDHE_GCM. Os pacotes de codificação ECDHE_CBC e DHE foram fornecidos para compatibilidade com esses sistemas operacionais.

Ao usar domínios personalizados com TLS 1.0 e 1.1 habilitado, os seguintes pacotes de codificação são suportados:

  • TLS_AES_256_GCM_SHA384 (apenas TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (apenas TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

O Azure Front Door não suporta a desativação ou configuração de pacotes de codificação específicos para o seu perfil.

Próximos passos