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 auto-assinados e certificados 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 é regida definindo a opção ignore-server-auth-failure no perfil de proxy SSL. Os resultados da configuração dessa opção estão disponíveis na Tabela 2.

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

Ação do perfil de proxy SSL	Resultados
A opção ignore-server-auth-failure não é 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 ca raiz no perfil de proxy. Se a autenticação falhar, a conexão cairá.
A opção ignore-server-auth-failure é 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 coincidir com o 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, porque 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 SSL derrubadas. Veja como ativar a depuração e o rastreamento do 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 de SSL

O aperto de mão SSL/TLS é um processo intensivo de 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 chaves 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 aperto de mão SSL/TLS, o proxy SSL pode apresentar o certificado interditado em cache ao cliente em vez de gerar o novo certificado interditado.

Melhorar o desempenho da 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 a retenção dos valores padrão.

Exemplo:

• (Opcional) Defina o valor do tempo limite do cache do certificado (por 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.

  Quando você desativa o cache de certificado, o dispositivo permite o aperto de mão completo do SSL para uma nova conexão. Por padrão, o cache do certificado é ativado.

• (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.

Retomada da sessão

A retomada da sessão 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 um aperto de mão SSL completo e da 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 tíquetes de sessão. Uma retomada da 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 Session ID identifica as informações em cache.

• Em conexões subseqüentes, ambas as partes concordam em usar o 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) em 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 aperto de mão inicial do TLS. Após um aperto de mão TLS bem-sucedido, o servidor envia uma identidade PSK para o cliente. O cliente usa essa identidade PSK nos futuros apertos de mão para negociar o uso do PSK associado para retomar a sessão.

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

1. Após um aperto de mão inicial do TLS, o servidor envia uma nova mensagem do Session Ticket ao 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 Hello.
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 iniciação SSL-I (SSL) usa PSK com o modo de troca de chaves ECDHE, e o SSL-T (encerramento de 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 de acordo com 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 do 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ões. Depois que uma sessão é criada e o transporte de túnel SSL é 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ões é útil nas seguintes situações:

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

• 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 ca confiável, então o sistema libera as entradas de cache quando você comete a política modificada. Nesse caso, é necessário um aperto de mão completo para estabelecer os novos parâmetros SSL. (Não há impacto nas 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 continua.

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

O StartTLS permite uma sessão SMTP 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 insegura existente para uma conexão SSL/TLS segura.

Você pode definir um limite que permite que você decida 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 ao 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). Depois de 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 atingir 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).