BLOG | NGINX

Descarregamento, criptografia e certificados SSL/TLS com NGINX e NGINX Plus

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Rick Nelson
Rick Nelson
Publicado em 30 de abril de 2014

O NGINX e o NGINX Plus oferecem uma série de recursos que permitem lidar com a maioria dos requisitos de SSL/TLS. Eles usam OpenSSL e o poder dos chips de processador padrão para fornecer desempenho SSL/TLS econômico. À medida que o poder dos chips de processador padrão continua a aumentar e os fornecedores de chips adicionam suporte à aceleração criptográfica, a vantagem de custo do uso de chips de processador padrão em vez de chips SSL/TLS especializados também continua a aumentar.

Descriptografar o tráfego HTTPS no NGINX traz muitos benefícios

Há três casos de uso principais para NGINX e NGINX Plus com SSL/TLS.

Descarregamento SSL/TLS

Quando o NGINX é usado como proxy, ele pode descarregar o processamento de descriptografia SSL dos servidores de backend. Há uma série de vantagens em fazer a descriptografia no proxy:

  • Desempenho aprimorado – O maior impacto no desempenho ao realizar a descriptografia SSL é o handshake inicial. Para melhorar o desempenho, o servidor que faz a descriptografia armazena em cache os IDs de sessão SSL e gerencia os tíquetes de sessão TLS. Se isso for feito no proxy, todas as solicitações do mesmo cliente poderão usar os valores armazenados em cache. Se isso for feito nos servidores de backend, cada vez que as solicitações do cliente forem para um servidor diferente, o cliente terá que se autenticar novamente. O uso de tickets 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 de backend – o processamento SSL/TLS consome muita CPU e está se tornando mais intensivo à medida que o tamanho das chaves aumenta. Remover esse trabalho dos servidores de backend permite que eles se concentrem no que fazem de mais eficiente: entregar conteúdo.
  • Roteamento inteligente – Ao descriptografar o tráfego, o proxy 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 adquiridos e instalados nos servidores proxy e não em todos os servidores backend. Isso economiza tempo e dinheiro.
  • Patches de segurança – Se surgirem vulnerabilidades na pilha SSL/TLS, os patches apropriados precisam ser aplicados apenas aos servidores proxy.

Para mais detalhes, consulte Terminação SSL do NGINX no Guia de administração do NGINX Plus.

Criptografia SSL/TLS para os servidores de origem

Há momentos em que você pode precisar que o NGINX criptografe o tráfego que ele envia para servidores de backend. Essas solicitações podem chegar ao servidor NGINX como texto simples ou como tráfego criptografado que o NGINX deve descriptografar para tomar uma decisão de roteamento.  Usar um pool de conexões keepalive com os servidores de backend minimiza o número de handshakes SSL/TLS e, portanto, maximiza o desempenho do SSL/TLS. Isso é obtido de forma muito simples configurando o NGINX para fazer proxy para “https” para que ele criptografe automaticamente o tráfego que ainda não está criptografado.

Criptografia de ponta a ponta

Como o NGINX pode fazer tanto a descriptografia quanto a criptografia, você pode obter criptografia de ponta a ponta de todas as solicitações com o NGINX ainda tomando decisões de roteamento da Camada 7. Neste caso, os clientes se comunicam com o NGINX por HTTPS, e ele descriptografa as solicitações e as criptografa novamente antes de enviá-las aos servidores de backend. Isso pode ser desejável quando o servidor proxy não está colocalizado em um data center com os servidores de backend. À medida que mais e mais servidores são movidos para a nuvem, torna-se mais necessário usar HTTPS entre um proxy e servidores de backend.

Certificados de Cliente

O NGINX pode manipular certificados de cliente SSL/TLS e pode ser configurado para torná-los opcionais ou obrigatórios . Os certificados de cliente são uma maneira de restringir o acesso aos seus sistemas somente a clientes pré-aprovados, sem exigir uma senha, e você pode controlar os certificados adicionando certificados revogados a uma lista de revogação de certificados (CRL), que o NGINX verifica para determinar se um certificado de cliente ainda é válido.

Recursos de segurança adicionais

Há vários outros recursos que ajudam a dar suporte a esses casos de uso, incluindo (mas não se limitando a) os seguintes:

  • Vários certificados – Uma única instância do NGINX pode oferecer suporte a muitos certificados para diferentes domínios e pode ser dimensionada para oferecer suporte a centenas de milhares de certificados. É um caso de uso comum ter uma instância do NGINX atendendo a muitos endereços IP e domínios, com cada domínio exigindo seu próprio certificado.
  • Grampeamento OCSP – Quando habilitado, o NGINX inclui uma resposta OCSP com registro de data e hora assinada pela autoridade de certificação que o cliente pode usar para verificar o certificado do servidor, evitando a perda de desempenho ao contatar o servidor OCSP diretamente.
  • Cifras SSL/TLS – Você pode especificar quais cifras estão habilitadas.
  • Protocolos SSL/TLS – Você pode especificar quais protocolos estão habilitados, incluindo SSLv2, SSLv3, TLSv1, TLSv1.1 e TLSv1.2.
  • Certificados encadeados – O NGINX suporta cadeias de certificados , usadas quando o certificado do site não é assinado diretamente pelo certificado raiz de uma CA (Autoridade Certificadora), mas sim por uma série de certificados intermediários. O servidor web apresenta uma 'cadeia de certificados' contendo os certificados intermediários, para que o cliente web possa verificar a cadeia de confiança que vincula o certificado do site a um certificado raiz confiável.
  • Otimizações do servidor HTTPS – O NGINX pode ser ajustado para maximizar seu desempenho SSL/TLS configurando o número de processos de trabalho, usando conexões keepalive e usando um cache de sessão SSL/TLS.

Para mais detalhes, confira estes recursos:

Exemplos

Aqui estão alguns exemplos de recursos de segurança do NGINX. Esses exemplos pressupõem uma compreensão básica da configuração do NGINX.

A configuração a seguir manipula o tráfego HTTP para www.example.com e o envia por proxy para um grupo upstream:

backends upstream {
servidor 192.168.100.100:80;
servidor 192.168.100.101:80;
}

servidor {
ouvir 80;
nome_do_servidor www.example.com;

localização / {
senha_do_proxy http://backends;
}
}

Agora adicione suporte a HTTPS para que o NGINX descriptografe o tráfego usando o certificado e a chave privada e se comunique com os servidores de backend via HTTP:

backends upstream { server 192.168.100.100:80; server 192.168.100.101:80; } server { listen 80; listen 443 ssl ; # O parâmetro 'ssl' informa ao NGINX para descriptografar o tráfego server_name www.example.com; ssl_certificate www.example.com.crt ; # O arquivo de certificado ssl_certificate_key www.example.com.key ; # O arquivo de chave privada location / { proxy_pass http://backends; } }

Ou se você receber tráfego por HTTP e enviá-lo aos servidores de backend por HTTPS:

backends upstream { server 192.168.100.100:443; server 192.168.100.101:443; } server { listen 80; server_name www.example.com; location / { proxy_pass https ://backends; # O prefixo 'https' informa ao NGINX para criptografar o tráfego } }

Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."