Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway

  • 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 navegador. Este link garante que todos os dados passados entre o servidor Web e os navegadores permaneçam privados e criptografados. O gateway de aplicativo suporta tanto a terminação TLS no gateway quanto a criptografia TLS de ponta a ponta.

Terminação TLS

O Application Gateway suporta terminação TLS no gateway, após o qual o tráfego normalmente flui sem criptografia para os servidores back-end. Há várias vantagens de fazer a terminação TLS no gateway de aplicativo:

  • Desempenho melhorado – O maior impacto de desempenho ao fazer a desencriptação TLS é o handshake inicial. Para melhorar o desempenho, o servidor que faz a descriptografia armazena em cache IDs de sessão TLS e gerencia tíquetes de sessão TLS. Se isso for feito no gateway de aplicativo, todas as solicitações do mesmo cliente poderão usar os valores armazenados em cache. Se isso for feito nos servidores de back-end, cada vez que as solicitações do cliente forem para um servidor diferente, o cliente deverá se autenticar novamente. O uso de tíquetes TLS pode ajudar a mitigar esse problema, mas eles não são suportados por todos os clientes e podem ser difíceis de configurar e gerenciar.
  • Melhor utilização dos servidores back-end – o processamento SSL/TLS é muito intensivo em CPU e está se tornando mais intensivo à medida que os tamanhos das chaves aumentam. Remover esse trabalho dos servidores back-end permite que eles se concentrem no que eles são mais eficientes, fornecendo conteúdo.
  • Roteamento inteligente – Ao descriptografar o tráfego, o gateway de aplicativo tem acesso ao conteúdo da solicitação, como cabeçalhos, URI e assim por diante, e pode usar esses dados para rotear solicitações.
  • Gerenciamento de certificados – Os certificados só precisam ser comprados e instalados no gateway de aplicativos e não em todos os servidores back-end. Isso economiza tempo e dinheiro.

Para configurar a terminação TLS, um certificado TLS/SSL deve ser adicionado ao ouvinte. Isso permite que o Application Gateway descriptografe o tráfego de entrada e criptografe o tráfego de resposta para o cliente. O certificado fornecido ao Application Gateway deve estar no formato PFX (Personal Information Exchange), que contém as chaves privada e pública. Os algoritmos PFX suportados estão listados na função PFXImportCertStore.

Importante

O certificado no ouvinte requer que toda a cadeia de certificados seja carregada (o certificado raiz da autoridade de certificação, os intermediários e o certificado folha) para estabelecer a cadeia de confiança.

Nota

O gateway de aplicativo não fornece nenhum recurso para criar um novo certificado ou enviar uma solicitação de certificado para uma autoridade de certificação.

Para que a conexão TLS funcione, você precisa garantir que o certificado TLS/SSL atenda às seguintes condições:

  • Que a data e hora atuais estão dentro do intervalo de datas "Válido de" e "Válido até" no certificado.
  • O “Nome Comum” (NC) do certificado corresponde ao cabeçalho do anfitrião no pedido. Por exemplo, se o cliente estiver a realizar um pedido para https://www.contoso.com/, o NC tem de ser www.contoso.com.

Se você tiver erros com o nome comum (CN) do certificado de back-end, consulte nosso guia de solução de problemas.

Certificados suportados para terminação TLS

O gateway de aplicativo oferece suporte aos seguintes tipos de certificados:

  • Certificado de autoridade de certificação (autoridade de certificação): um certificado de autoridade de certificação é um certificado digital emitido por uma autoridade de certificação (CA)
  • Certificado EV (Extended Validation): um certificado EV é um certificado que está em conformidade com as diretrizes de certificado padrão da indústria. Isso tornará a barra do localizador do navegador verde e publicará o nome da empresa também.
  • Certificado curinga: este certificado suporta qualquer número de subdomínios com base em *.site.com, onde seu subdomínio substituiria o *. No entanto, ele não suporta site.com, portanto, caso os usuários estejam acessando seu site sem digitar o "www" à esquerda, o certificado curinga não cobrirá isso.
  • Certificados autoassinados: os navegadores clientes não confiam nesses certificados e avisarão o usuário de que o certificado do serviço virtual não faz parte de uma cadeia de confiança. Os certificados autoassinados são bons para testes ou ambientes em que os administradores controlam os clientes e podem ignorar com segurança os alertas de segurança do navegador. As cargas de trabalho de produção nunca devem usar certificados autoassinados.

Para obter mais informações, consulte Configurar a terminação TLS com o gateway de aplicativo.

Tamanho do certificado

Verifique a seção Limites do Application Gateway para saber o tamanho máximo do certificado TLS/SSL suportado.

Encriptação TLS ponto a ponto

Talvez você não queira comunicação não criptografada para os servidores de back-end. Você pode ter requisitos de segurança, requisitos de conformidade ou o aplicativo só pode aceitar uma conexão segura. O Gateway de Aplicativo do Azure tem criptografia TLS de ponta a ponta para dar suporte a esses requisitos.

O TLS de ponta a ponta permite criptografar e transmitir com segurança dados confidenciais para o back-end enquanto usa os recursos de balanceamento de carga Layer-7 do Application Gateway. Esses recursos incluem afinidade de sessão baseada em cookies, roteamento baseado em URL, suporte para roteamento baseado em sites, a capacidade de reescrever ou injetar cabeçalhos X-Forwarded-* e assim por diante.

Quando configurado com o modo de comunicação TLS de ponta a ponta, o Application Gateway encerra as sessões TLS no gateway e descriptografa o tráfego do usuário. Em seguida, aplica as regras configuradas para selecionar uma instância de conjunto de back-end adequada para encaminhar o tráfego. Em seguida, o Application Gateway inicia uma nova conexão TLS com o servidor back-end e criptografa novamente os dados usando o certificado de chave pública do servidor back-end antes de transmitir a solicitação para o back-end. Qualquer resposta do servidor Web atravessa o mesmo processo para o utilizador final. O TLS de ponta a ponta é habilitado definindo a configuração de protocolo em Configuração HTTP de back-end como HTTPS, que é então aplicada a um pool de back-end.

Nos gateways SKU do Application Gateway v1, a política TLS aplica a versão TLS somente ao tráfego frontend e às cifras definidas aos destinos frontend e backend. Nos gateways SKU do Application Gateway v2, a política TLS só se aplica ao tráfego frontend, as conexões TLS de back-end sempre serão negociadas por meio das versões TLS 1.0 a TLS 1.2.

O Application Gateway só se comunica com os servidores back-end que têm permissão para listar seu certificado com o Application Gateway ou cujos certificados são assinados por autoridades de CA conhecidas e o CN do certificado corresponde ao nome do host nas configurações de back-end HTTP. Estes incluem os serviços fidedignos do Azure, como o Serviço de Aplicações Web/Aplicações Web do Azure e a Gestão de API do Azure.

Se os certificados dos membros no pool de back-end não forem assinados por autoridades de CA conhecidas, cada instância no pool de back-end com TLS de ponta a ponta habilitado deverá ser configurada com um certificado para permitir uma comunicação segura. Adicionar o certificado garante que o gateway de aplicativo se comunique apenas com instâncias de back-end conhecidas. Isso garante ainda mais a comunicação de ponta a ponta.

Nota

O certificado adicionado à Configuração HTTP de back-end para autenticar os servidores back-end pode ser o mesmo que o certificado adicionado ao ouvinte para terminação TLS no gateway de aplicativo ou diferente para segurança aprimorada.

end to end TLS scenario

Neste exemplo, as solicitações usando TLS1.2 são roteadas para servidores back-end no Pool1 usando TLS de ponta a ponta.

TLS de ponta a ponta e permitir a listagem de certificados

O Application Gateway só se comunica com os servidores back-end que têm permissão para listar seu certificado com o Application Gateway ou cujos certificados são assinados por autoridades de CA conhecidas e o CN do certificado corresponde ao nome do host nas configurações de back-end HTTP. Há algumas diferenças no processo de configuração de TLS de ponta a ponta em relação à versão do Application Gateway usada. A seção a seguir explica as versões individualmente.

TLS de ponta a ponta com o SKU v1

Para habilitar o TLS de ponta a ponta com os servidores back-end e para que o Application Gateway roteie solicitações para eles, os testes de integridade devem ter êxito e retornar uma resposta íntegra.

Para testes de integridade HTTPS, a SKU do Application Gateway v1 usa uma correspondência exata do certificado de autenticação (chave pública do certificado do servidor back-end e não do certificado raiz) a ser carregado nas configurações HTTP.

Somente conexões com back-ends conhecidos e permitidos são permitidas. Os restantes backends são considerados insalubres pelas sondas de saúde. Os certificados autoassinados são apenas para fins de teste e não são recomendados para cargas de trabalho de produção. Esses certificados devem ser permitidos com o gateway de aplicativo, conforme descrito nas etapas anteriores, antes de poderem ser usados.

Nota

A autenticação e a configuração de certificado raiz confiável não são necessárias para serviços confiáveis do Azure, como o Serviço de Aplicativo do Azure. Eles são considerados confiáveis por padrão.

TLS de ponta a ponta com o SKU v2

Os Certificados de Autenticação foram preteridos e substituídos por Certificados Raiz Confiáveis na SKU do Application Gateway v2. Eles funcionam de forma semelhante aos Certificados de Autenticação com algumas diferenças importantes:

  • Os certificados assinados por autoridades de autoridade de certificação conhecidas cujo CN corresponde ao nome do host nas configurações de back-end HTTP não exigem nenhuma etapa adicional para que o TLS de ponta a ponta funcione.

    Por exemplo, se os certificados de back-end forem emitidos por uma autoridade de certificação conhecida e tiver um CN de contoso.com, e o campo de host da configuração http de back-end também estiver definido como contoso.com, nenhuma etapa adicional será necessária. Você pode definir o protocolo de configuração http de back-end como HTTPS e tanto a sonda de integridade quanto o caminho de dados seriam TLS habilitados. Se você estiver usando o Serviço de Aplicativo do Azure ou outros serviços Web do Azure como seu back-end, eles também serão implicitamente confiáveis e nenhuma etapa adicional será necessária para TLS de ponta a ponta.

Nota

Para que um certificado TLS/SSL seja confiável, esse certificado do servidor back-end deve ter sido emitido por uma autoridade de certificação bem conhecida. Se o certificado não tiver sido emitido por uma autoridade de certificação confiável, o gateway de aplicativo verificará se o certificado da autoridade de certificação emissora foi emitido por uma autoridade de certificação confiável e assim por diante até que uma autoridade de certificação confiável seja encontrada (quando uma conexão confiável e segura será estabelecida) ou nenhuma autoridade de certificação confiável possa ser encontrada (momento em que o gateway de aplicativo marcará o back-end como não íntegro). Portanto, é recomendável que o certificado do servidor back-end contenha as CAs raiz e intermediária.

  • Se o certificado do servidor back-end for autoassinado ou assinado por CA/intermediários desconhecidos, para habilitar o TLS de ponta a ponta no Application Gateway v2, um certificado raiz confiável deverá ser carregado. O Application Gateway só se comunicará com back-ends cujo certificado raiz do certificado do servidor corresponda a um da lista de certificados raiz confiáveis na configuração http de back-end associada ao pool.

  • Além da correspondência de certificado raiz, o Application Gateway v2 também valida se a configuração Host especificada na configuração http de back-end corresponde à do nome comum (CN) apresentado pelo certificado TLS/SSL do servidor de back-end. Ao tentar estabelecer uma conexão TLS com o back-end, o Application Gateway v2 define a extensão SNI (Server Name Indication) para o Host especificado na configuração http de back-end.

  • Se escolher o nome do host do destino de back-end em vez do campo Host na configuração http do back-end, o cabeçalho SNI será sempre definido como o FQDN do pool de back-end e o CN no certificado TLS/SSL do servidor de back-end deverá corresponder ao seu FQDN. Os membros do pool de back-end com IPs não são suportados neste cenário.

  • O certificado raiz é um certificado raiz codificado em base64 dos certificados do servidor back-end.

Diferenças de SNI no SKU v1 e v2

Como mencionado anteriormente, o Application Gateway encerra o tráfego TLS do cliente no Application Gateway Listener (vamos chamá-lo de conexão frontend), descriptografa o tráfego, aplica as regras necessárias para determinar o servidor back-end para o qual a solicitação deve ser encaminhada e estabelece uma nova sessão TLS com o servidor back-end (vamos chamá-lo de conexão back-end).

As tabelas a seguir descrevem as diferenças no SNI entre o SKU v1 e v2 em termos de conexões frontend e backend.

Conexão TLS frontend (cliente para gateway de aplicativo)

Scenario v1 v2
Se o cliente especificar o cabeçalho SNI e todos os ouvintes multissite estiverem habilitados com o sinalizador "Exigir SNI" Retorna o certificado apropriado e, se o site não existir (de acordo com o server_name), a conexão será redefinida. Retorna o certificado apropriado se disponível, caso contrário, retorna o certificado do primeiro ouvinte HTTPS de acordo com a ordem especificada pelas regras de roteamento de solicitação associadas aos ouvintes HTTPS
Se o cliente não especificar um cabeçalho SNI e se todos os cabeçalhos multissite estiverem habilitados com "Exigir SNI" Redefine a conexão Retorna o certificado do primeiro ouvinte HTTPS de acordo com a ordem especificada pelas regras de roteamento de solicitação associadas aos ouvintes HTTPS
Se o cliente não especificar o cabeçalho SNI e se houver um ouvinte básico configurado com um certificado Retorna o certificado configurado no ouvinte básico para o cliente (certificado padrão ou de fallback) Retorna o certificado configurado no ouvinte básico

Gorjeta

O sinalizador SNI pode ser configurado com o PowerShell ou usando um modelo ARM. Para obter mais informações, consulte RequireServerNameIndication e Guia de início rápido: tráfego da Web direto com o Azure Application Gateway - modelo ARM.

Conexão TLS de back-end (gateway de aplicativo para o servidor back-end)

Para tráfego de sonda

Scenario v1 v2
Cabeçalho SNI (server_name) durante o handshake TLS como FQDN Defina como FQDN do pool de back-end. De acordo com a RFC 6066, endereços IPv4 e IPv6 literais não são permitidos no nome do host SNI.
Nota: O FQDN no pool de back-end deve ser resolvido pelo DNS para o endereço IP do servidor de back-end (público ou privado)		 O cabeçalho SNI (server_name) é definido como o nome do host do teste personalizado anexado às configurações HTTP (se configurado), caso contrário, do nome do host mencionado nas configurações HTTP, caso contrário, do FQDN mencionado no pool de back-end. A ordem de precedência é o pool de back-end de configurações HTTP de > sonda > personalizada.
Nota: Se os nomes de host configurados nas configurações HTTP e no teste personalizado forem diferentes, então, de acordo com a precedência, o SNI será definido como o nome do host do teste personalizado.
Se o endereço do pool de back-end for um endereço IP (v1) ou se o nome de host da sonda personalizada estiver configurado como endereço IP (v2) SNI (server_name) não será definido.
Nota: Nesse caso, o servidor back-end deve ser capaz de retornar um certificado padrão/fallback e isso deve ser permitido listado nas configurações HTTP em certificado de autenticação. Se não houver nenhum certificado padrão/fallback configurado no servidor back-end e o SNI for esperado, o servidor poderá redefinir a conexão e levará a falhas de teste		 Na ordem de precedência mencionada anteriormente, se eles tiverem endereço IP como nome de host, o SNI não será definido de acordo com a RFC 6066.
Nota: SNI também não será definido em testes v2 se nenhum teste personalizado estiver configurado e nenhum nome de host estiver definido nas configurações HTTP ou no pool de back-end

Nota

Se uma sonda personalizada não estiver configurada, o Application Gateway enviará uma sonda padrão neste formato - <protocol>://127.0.0.1:<port>/. Por exemplo, para uma sonda HTTPS padrão, ela será enviada como https://127.0.0.1:443/. Observe que, o 127.0.0.1 mencionado aqui é usado apenas como cabeçalho de host HTTP e, de acordo com RFC 6066, não será usado como cabeçalho SNI. Para obter mais informações sobre erros de teste de integridade, consulte o guia de solução de problemas de integridade de back-end.

Para tráfego ao vivo

Scenario v1 v2
Cabeçalho SNI (server_name) durante o handshake TLS como FQDN Defina como FQDN do pool de back-end. De acordo com a RFC 6066, endereços IPv4 e IPv6 literais não são permitidos no nome do host SNI.
Nota: O FQDN no pool de back-end deve ser resolvido pelo DNS para o endereço IP do servidor de back-end (público ou privado)		 O cabeçalho SNI (server_name) é definido como o nome do host nas configurações HTTP, caso contrário, se a opção PickHostnameFromBackendAddress for escolhida ou se nenhum nome de host for mencionado, ele será definido como o FQDN na configuração do pool de back-end
Se o endereço do pool de back-end for um endereço IP ou o nome do host não estiver definido nas configurações HTTP SNI não será definido de acordo com RFC 6066 se a entrada do pool de back-end não for um FQDN SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deve corresponder a esse nome de host.
O nome do host não é fornecido nas Configurações HTTP, mas um FQDN é especificado como o Destino para um membro do pool de back-end SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deve corresponder a esse nome de host. SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deve corresponder a esse nome de host.

Próximos passos

Depois de aprender sobre TLS de ponta a ponta, vá para Configurar TLS de ponta a ponta usando o Application Gateway com PowerShell para criar um gateway de aplicativo usando TLS de ponta a ponta.