Certificados SSL

Autenticação de servidor

A confiança implícita entre o cliente e o dispositivo (porque o cliente aceita o certificado gerado pelo dispositivo) é um aspecto importante do proxy SSL. É extremamente importante que a autenticação do servidor não seja comprometida; no entanto, na realidade, certificados e certificados auto-assinados com anomalias estão em abundância. Anomalias podem incluir certificados expirados, instâncias de nome comum que não correspondem a um nome de domínio e assim por diante.

A autenticação do servidor é governada definindo a opção ignore-server-auth-failure no perfil de proxy SSL. Os resultados da configuração desta opção estão disponíveis na Tabela 1.

Tabela 1: ignore a opção de falha na autenticação do servidor

Ação de perfil de proxy SSL	Resultados
A opção ignore-server-auth-failure não está definida (opção padrão)	Se a autenticação for bem sucedida, um novo certificado é gerado substituindo as chaves e alterando o nome do emissor para o nome do emissor que está configurado no certificado de CA raiz no perfil de proxy. Se a autenticação falhar, a conexão será perdida.
A opção ignore-server-auth-failure está definida	Se o certificado for auto-assinado, um novo certificado é gerado substituindo as chaves. O nome do emissor não foi alterado. Isso garante que o navegador do cliente exibe um aviso de que o certificado não é válido. Se o certificado tiver expirado ou se o nome comum não corresponder ao nome do domínio, um novo certificado será gerado substituindo as chaves e alterando o nome do emissor para SSL-PROXY: DUMMY_CERT:GERADO DEVIDO À FALHA DO SRVR AUTH. Isso garante que o navegador do cliente exibe um aviso de que o certificado não é válido. Não recomendamos essa opção de autenticação, pois configurá-la resulta em sites que não estão sendo autenticados. No entanto, você pode usar essa opção para identificar efetivamente a causa raiz para sessões de SSL perdidas. Veja a habilitação de depuração e rastreamento para proxy SSL.

Autenticação do cliente

Atualmente, a autenticação do cliente não é suportada em proxy SSL. Se um servidor solicitar a autenticação do cliente, um aviso é emitido de que um certificado não está disponível. O aviso permite que o servidor determine se deve continuar ou sair.

Otimizando o desempenho do SSL

O SSL/TLS é um processo intensivo em CPU. Como o SSL/TLS é o protocolo de segurança mais usado na web, seu desempenho resulta em impacto significativo no desempenho da Web.

A partir do Junos OS Release 15.1X49-D120, você pode usar as seguintes opções para otimizar o desempenho:

• Use trocas de chave RSA otimizadas

• Use criptografia autenticada com dados associados (AEAD)— AES128-CBC-SHA, AES256-CBC-SHA

• Manutenção do cache de certificado — o cache de certificado armazena o certificado de servidor interditado junto com os detalhes do certificado do servidor. Durante o sSL/TLS, o proxy SSL pode apresentar o certificado interdiciado em cache ao cliente em vez de gerar o novo certificado interditado.

Melhorar o desempenho do SSL resulta em um melhor desempenho do site sem comprometer a segurança e maximizar a experiência do usuário.

Você pode configurar opcionalmente as seguintes configurações para o cache do seu certificado. No entanto, recomendamos manter os valores padrão.

Exemplo:

• (Opcional) Defina o valor de tempo limite do cache do certificado (exemplo: 300 segundos) .

  Neste exemplo, o cache do certificado armazena os detalhes do certificado por 300 segundos. O valor de tempo limite padrão é de 600 segundos.

• (Opcional) Desativar o cache do certificado.

  Ao desativar o cache de certificados, o dispositivo permite que o SSL seja totalmente responsável por uma nova conexão. O cache de certificado padrão é habilitado.

• (Opcional) Invalide o cache de certificado existente.

  Neste exemplo, o dispositivo invalida o cache de certificado existente quando a lista de revogação de certificados (CRL) é atualizada. Por padrão, o cache de certificado inválido na atualização do CRL é desativado.

Resumption de sessão

A retomada da sessão da SSL fornece um mecanismo para retomar uma sessão anterior usando IDs de sessão já negociados. A retomada da sessão salva o cliente e o servidor da sobrecarga computacional de uma SSL completa e geração de novas chaves primárias.

A retomada da sessão reduz o processo de aperto de mão e acelera as transações de SSL, resultando em um melhor desempenho, mantendo o nível apropriado de segurança.

O TLS 1.2 oferece suporte à retomada da sessão com identificadores de sessão e mecanismos de tickets de sessão. Uma retomada de sessão SSL inclui as seguintes etapas:

• Um mecanismo de cache de sessão armazena informações de sessão, como a chave secreta pré-mestre e cifras acordadas para o cliente e o servidor.

• O ID de sessão identifica as informações em cache.

• Em conexões subseqüentes, ambas as partes concordam em usar a ID da sessão para recuperar as informações em vez de criar uma chave secreta pré-mestre.

A partir do Junos OS Release 22.1R1, o TLS 1.3 oferece suporte à retomada da sessão usando uma chave pré-compartilhada (PSK) no proxy SSL. A retomada da sessão usando o PSK permite retomar uma sessão com uma chave secreta compartilhada previamente estabelecida para reduzir a sobrecarga de aperto de mão da SSL.

O PSK é uma chave de criptografia exclusiva derivada do TLS inicial. Após um sucesso no TLS, o servidor envia uma identidade PSK para o cliente. O cliente usa essa identidade PSK em futuros apertos de mão para negociar o uso do PSK associado para retomar a sessão.

Uma retomada da sessão de SSL com o TLS1.3 inclui as seguintes etapas:

1. Após um aperto inicial de TLS, o servidor envia uma nova mensagem de Session Ticket para o cliente, que contém a identidade PSK (cópia criptografada do PSK).

2. Da próxima vez, quando o cliente tentar retomar a sessão, ele envia o mesmo Bilhete de Sessão para o servidor na mensagem Olá.
3. O servidor descriptografa a mensagem, identifica o PSK e recupera as informações da sessão de seu cache para retomar a sessão.

Uma SSL-I (iniciação SSL) usa psk com modo de troca de chave ECDHE, e SSL-T (terminação SSL) usa PSK e PSK com modos de intercâmbio ECDHE.

A sessão de proxy SSL oferece suporte à interoperabilidade entre TLS1.3 e TLS1.2 e versões anteriores em duas extremidades de uma conexão para a retomada da sessão.

Por padrão, a retomada da sessão é habilitada para proxy SSL. Você pode limpar a retomada da sessão ou reativar conforme os seus requisitos.

• Para limpar a retomada da sessão:
• Para reativar a retomada da sessão:

Use o comando a seguir para configurar o valor do tempo de sessão.

Você pode configurar o valor de tempo limite entre 300 segundos e 86400 segundos. O valor padrão é de 86400 segundos (24 horas).

Renegociação de sessão

O firewall da Série SRX oferece suporte à renegociação de sessão. Após a criação de uma sessão e o transporte de túneis SSL ser estabelecido, uma mudança nos parâmetros SSL requer renegociação. O proxy SSL oferece suporte a renegociações seguras (RFC 5746) e não seguras (TLS v1.0, TLS v1.1 e TLS v1.2). Quando a retomada da sessão é habilitada, a renegociação de sessão é útil nas seguintes situações:

• As chaves de cifra precisam ser atualizadas após uma sessão de SSL prolongada.

• Cifras mais fortes precisam ser aplicadas para uma conexão mais segura.

Se você modificar o perfil de proxy SSL alterando um certificado, ou força de cifra ou lista de CA confiável, então o sistema libera as entradas de cache quando você confirma a política modificada. Neste caso, é necessário um completo aperto de mão para estabelecer os novos parâmetros SSL. (Não há impacto em sessões não-SSL.)

Se o perfil de proxy SSL não for alterado, as entradas de cache correspondentes a esse perfil não serão liberadas e a sessão continuará.

Negociação de StartTLS para sessões de SMTP

O StartTLS permite uma sessão de SMTP a partir de uma conexão TCP simples inicial para uma conexão TLS mais segura. O StartTLS permite a sessão de SMTP entre o servidor e o cliente na camada TLS após uma negociação bem-sucedida entre os pares. O StartTLS atualiza uma conexão SMTP simples e inexistentes para uma conexão SSL/TLS segura.

Você pode definir um limite que lhe permita decidir quanto tempo esperar antes de ignorar a sessão se o StartTLS não for recebido do cliente.

Você pode configurar as seguintes opções:

• byte-threshold — bytes mínimos de sessão não criptografada permitidos antes de ignorar a sessão se o StartTLS não for recebido do cliente. Faixa de 100 a 300.
• limite de pacote — número de pacotes não criptografados permitidos na direção do cliente para servidor antes de ignorar a sessão se o StartTLS não for recebido do cliente. Faixa de 1 a 15.

Exemplo:

Neste exaple, o proxy SSL permite 100 bytes de tráfego SMTP simples (não criptografado). Após atingir 100 bytes, ele ignora a sessão se o StartTLS não for recebido do cliente.

Neste exemplo, o proxy SSL permite 2 pacotes de tráfego SMTP simples (não criptografado). Após chegar a 2 pacotes, ele ignora a sessão se o StartTLS não for recebido do cliente.

Resolução dinâmica de nomes de domínio

Os endereços IP associados a nomes de domínio são dinâmicos e podem mudar a qualquer momento. Sempre que um endereço IP de domínio muda, ele é propagado para a configuração de proxy SSL (semelhante ao que é feito na configuração da política de firewall).