SSL /TLS Melhores práticas para 2023

Em 2023, protegendo seu site com um SSL /TLS certificado não é mais opcional, mesmo para empresas que não lidam diretamente com informações confidenciais de clientes na web. Mecanismos de pesquisa como o Google usam a segurança do site como um sinal de classificação de SEO, e navegadores populares como o Chrome alertam os usuários para sites que não usam HTTPS:

Navegador trabalhando para sites inseguros

No entanto, a perspectiva de configurar seus servidores web e aplicativos para usar o SSL /TLS protocolo corretamente pode parecer assustador, pois há muitas configurações misteriosas e opções de design a serem feitas. Este guia fornece uma visão geral rápida dos principais pontos a serem considerados ao configurar SSL /TLS para o seu site, focando na segurança e no desempenho. Ainda há muito a ser abordado apenas com o básico, então dividimos em uma série de etapas.

SSL.com fornece uma ampla variedade de SSL/TLS certificados do servidor. Proteja seu site hoje com um certificado SSL da SSL.com e construir confiança com seus visitantes!

COMPARAR SSL /TLS CERTIFICADOS

Escolha uma autoridade de certificação confiável (CA)

Seus certificados são tão confiáveis ​​quanto a CA que os emite. Todas as CAs de confiança pública estão sujeitas a auditorias rigorosas de terceiros para manter sua posição nos principais sistemas operacionais e programas de certificação de raiz do navegador, mas alguns são melhores em manter esse status do que outros. Procure um CA que (como SSL.com):

  • A maior parte de seus negócios está na área de confiança pública PKI. Essas empresas têm mais a perder se as más práticas de segurança aparecerem e tudo a ganhar acompanhando os padrões da indústria em evolução.
  • Responde com eficiência e eficácia às descobertas de vulnerabilidade que afetam a segurança e privacidade do usuário, como o de todo o setor entropia do número de série edição do início de 2019. Pesquisando em fóruns do setor, como mozilla.dev.security.policy pode lhe dar uma boa idéia sobre como uma CA específica reage às adversidades.
  • Oferece produtos e serviços úteis, como certificados de validação estendida (EV), emissão de certificados em massa / automatizada por meio de um intuitivo API ou de Protocolo ACME, serviços fáceis de gerenciamento e monitoramento do ciclo de vida do certificado e ajuda para integração com uma extensa lista de soluções de terceiros.
  • Tem uma reputação de ótimo atendimento ao cliente e suporte técnico. Manter o site da sua empresa seguro 100% do tempo é importante, e você precisa ser capaz de falar com um especialista de verdade ao telefone quando algo der errado.

Autoridade de Autoridade de Certificação (CAA)

Autoridade de Autoridade de Certificação (CAA) é um padrão para proteger sites, designando CAs específicos que têm permissão para emitir certificados para um nome de domínio. Depois de escolher um CA, você deve considerar configurar registros CAA para autorizá-lo.

Gere e proteja suas chaves privadas

A SSL /TLS protocolo utiliza um par de chaves para autenticar identidades e criptografar informações enviadas pela Internet. Um deles (o chave pública) destina-se a ampla distribuição e o outro (o chave privada) deve ser mantido o mais seguro possível. Essas chaves são criadas juntas quando você gera um solicitação de assinatura de certificado (CSR). Aqui estão alguns indicadores a serem lembrados em relação às suas chaves privadas:

  • Use chaves privadas fortes: Teclas maiores são mais difíceis de decifrar, mas requerem mais sobrecarga de computação. Atualmente, recomenda-se pelo menos uma chave RSA de 2048 bits ou uma chave ECDSA de 256 bits, e a maioria dos sites pode obter boa segurança enquanto otimiza o desempenho e a experiência do usuário com esses valores.
    Nota: para uma visão geral desses dois algoritmos, consulte o artigo SSL.com, Comparando ECDSA vs RSA.
  • Proteja suas chaves privadas:
    • Gere suas próprias chaves privadas em um ambiente seguro e confiável (de preferência no servidor onde serão implementadas ou em um dispositivo compatível com FIPS ou Common Criteria). Nunca permitir que uma CA (ou qualquer outra pessoa) gere chaves privadas em seu nome. Uma CA pública de boa reputação, como SSL.com, nunca se oferecerá para gerar ou manipular suas chaves privadas, a menos que sejam geradas em um token de hardware seguro ou HSM e não sejam exportáveis.
    • Apenas dê acesso às chaves privadas conforme necessário. Gere novas chaves e revogar todos os certificados das chaves antigas quando os funcionários com acesso à chave privada deixam a empresa.
    • Renove os certificados sempre que possível (pelo menos uma vez por ano seria bom), de preferência usando uma chave privada recém-gerada a cada vez. Ferramentas de automação como o Protocolo ACME são úteis para agendar renovações de certificados frequentes.
    • Se uma chave privada foi (ou pode ter sido) comprometida, revogar todos os certificados para esta chave, gere um novo par de chaves e emita um novo certificado para o novo par de chaves.

Configure o seu servidor

Na superfície, instalando um SSL /TLS certificado pode parecer uma operação simples; no entanto, ainda há muitas decisões de configuração que devem ser feitas para garantir que seu servidor da web seja rápido e seguro e que os usuários finais tenham uma experiência tranquila, livre de erros e avisos do navegador. Aqui estão algumas dicas de configuração para ajudar a colocá-lo no caminho certo ao configurar SSL /TLS nos seus servidores:

  • Certifique-se de que todos os nomes de host estão cobertos: O seu certificado cobre o nome de domínio do seu site com e sem o www prefixo? Tem alguma Nome alternativo da entidade (SAN) para cada nome de domínio que o certificado se destina a proteger?
  • Instalar cadeias de certificados completas: SSL de entidade final /TLS certificados são geralmente assinados por certificados intermediários em vez de uma chave raiz de CA. Certifique-se de que todos os certificados intermediários estejam instalados em seu servidor web para fornecer aos navegadores um completo caminho de certificação e evitar avisos e erros de confiança para os usuários finais. Seu CA será capaz de fornecer-lhe quaisquer intermediários necessários; Os clientes de SSL.com podem usar nosso Download intermediário de certificado página para recuperar pacotes intermediários para muitas plataformas de servidor.
  • Usar SSL atual /TLS Protocolos (TLS 1.2 ou 1.3): No final de 2018, todos os principais fornecedores de navegadores anunciaram planos de descontinuar TLS 1.0 e 1.1 no primeiro semestre de 2020. Google obsoleta TLS v1.0 e v1.1 no Chrome 72 (lançado em 30 de janeiro de 2919). As versões 84 do Chrome (lançadas em 14 de julho de 2020) e posteriores apresentam um aviso intersticial para esses protocolos, e o suporte estava programado para ser totalmente removido em maio de 2021. Suporte generalizado de navegador para SSL /TLS versões, como SSL v3, já se foram. Enquanto TLS 1.2 é atualmente a versão mais usada do SSL /TLS protocolo, TLS 1.3 (a versão mais recente) é já suportado nas versões atuais da maioria dos principais navegadores da web.
  • Use uma lista curta de conjuntos seguros de criptografia: Escolha apenas conjuntos de criptografia que oferecem criptografia de pelo menos 128 bits ou mais forte quando possível. O Instituto Nacional de Padrões e Tecnologia (NIST) também recomenda que todos TLS as implementações mudam de conjuntos de cifras contendo a cifra DES (ou suas variantes) para aqueles que usam AES. Finalmente, o uso de apenas um pequeno subconjunto de pacotes de criptografia potencialmente aceitáveis ​​minimiza a superfície de ataque para vulnerabilidades ainda não descobertas. O apêndice de SSL.com's Guia para TLS Conformidade com as normas fornece exemplos de configurações para as plataformas de servidor da Web mais populares, usando TLS 1.2.
    Nota: O uso de cifras não seguras e obsoletas (como RC4) pode causar erros de segurança do navegador, como ERR_SSL_VERSION_OR_CIPHER_MISMATCH no Google Chrome.
  • Use o sigilo direto (FS): Também conhecido como sigilo direto perfeito (PFS), O FS garante que uma chave privada comprometida também não comprometa as chaves da sessão anterior. Para habilitar o FS:
    • configurar TLS 1.2 para usar o algoritmo de troca de chaves Elliptic Curve Diffie-Hellman (EDCHE) (com DHE como substituto) e evite a troca de chaves RSA completamente, se possível.
    • Use TLS 1.3. TLS 1.3 fornece sigilo para todos TLS sessões através do Diffie-Hellman efêmero (EDH ou DHE) protocolo de troca de chaves.
  • permitir TLS Reinício da sessão: De maneira semelhante ao uso de keepalives para manter conexões TCP persistentes, TLS a retomada da sessão permite que o seu servidor web acompanhe o SSL / negociado recentementeTLS sessões e retome-as, ignorando a sobrecarga computacional da negociação de chaves da sessão.
  • Considere o grampeamento OCSP: Grampeamento OCSP permite que os servidores da web forneçam informações de revogação em cache diretamente para o cliente, o que significa que um navegador não terá que entrar em contato com um servidor OCSP para verificar se o certificado de um site foi revogado. Ao eliminar essa solicitação, o grampeamento OCSP oferece um aumento real de desempenho. Para obter mais informações, leia nosso artigo, Otimização de carregamento de página: grampeamento OCSP.

Use as práticas recomendadas para o design de aplicativos da Web

Projetar seus aplicativos da web com a segurança em mente é tão importante quanto configurar seu servidor corretamente. Esses são os pontos mais importantes para garantir que seus usuários não sejam expostos a homem no meio ataques e que seu aplicativo obtenha os benefícios de SEO que vêm com boas práticas de segurança:

  • Eliminar conteúdo misto: Arquivos JavaScript, imagens e arquivos CSS devem todos os ser acessado com SSL /TLS. Conforme descrito no artigo SSL.com, HTTPS Everywhereservindo conteúdo misto não é mais uma maneira aceitável de aumentar o desempenho do site e pode resultar em avisos de segurança do navegador e problemas de SEO.
  • Use cookies seguros: Configurando o Secure A sinalização nos cookies reforçará a transmissão por canais seguros (por exemplo, HTTPS). Você também pode impedir que o JavaScript do cliente acesse cookies via HttpOnly e restringir o uso entre sites de cookies com o SameSite bandeira.
  • Avalie o código de terceiros: Certifique-se de compreender os riscos potenciais do uso de bibliotecas de terceiros em seu site, como a possibilidade de introduzir inadvertidamente vulnerabilidades ou código malicioso. Sempre verifique a confiabilidade de terceiros com o melhor de sua capacidade e vincule a todos os códigos de terceiros com HTTPS. Por fim, certifique-se de que vale o risco se beneficiar de quaisquer elementos de terceiros em seu site.

Verifique seu trabalho com ferramentas de diagnóstico

Depois de configurar SSL /TLS no seu servidor e site ou fazendo qualquer alteração de configuração, é importante certificar-se de que tudo está configurado corretamente e que o seu sistema está seguro. Várias ferramentas de diagnóstico estão disponíveis para verificar o SSL / do seu siteTLS. Por exemplo, SSL Shopper's Verificador SSL irá informá-lo se o seu certificado está instalado corretamente, quando irá expirar, e exibirá o certificado cadeia de confiança.

Estão disponíveis outras ferramentas e aplicativos online que rastrearão seu site, procurando problemas de segurança, como conteúdo misto. Você também pode verificar se há conteúdo misto com um navegador da Web usando suas ferramentas de desenvolvedor internas:

aviso de conteúdo misto
Aviso de conteúdo misto no console do Chrome

Quaisquer que sejam as ferramentas que você escolher, também é importante definir uma programação para verificar o seu SSL /TLS instalação e configuração. Seu CA também pode ajudá-lo com isso; por exemplo, como uma conveniência para nossos clientes, SSL.com fornece notificações automatizadas de expiração de certificado iminente.


Implementar HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) é um mecanismo de política de segurança que ajuda a proteger sites contra ataques de downgrade de protocolo e sequestro de cookies. Ele permite que os servidores da Web declarem que os navegadores da Web (ou outros agentes de usuário compatíveis) só devem interagir com ele usando conexões HTTPS seguras e nunca por meio do protocolo HTTP inseguro. Essa política é comunicada pelo servidor ao agente do usuário por meio de um campo de cabeçalho de resposta HTTP denominado “Strict-Transport-Security”.

Implementar Segurança de Transporte Estrito HTTP (HSTS), você precisa adicionar um cabeçalho de resposta especial à configuração do seu servidor web.

Aqui está um guia passo a passo:

  1. Certifique-se de que seu site suporta HTTPS: Antes de habilitar o HSTS, seu site deve ter um válido Certificado SSL e ser capaz de servir conteúdo por HTTPS. Se seu site ainda não estiver configurado para HTTPS, você precisará obter um certificado SSL e configure seu servidor para usá-lo.
O cabeçalho sempre define Strict-Transport-Security "max-age=31536000; includeSubDomains"

Esta linha informa ao navegador para sempre usar HTTPS para o seu site no próximo ano (31,536,000 segundos), incluindo todos os subdomínios.

 

  1. Teste sua configuração: depois de adicionar o cabeçalho HSTS, você deve testar seu site para garantir que está funcionando corretamente. Você pode fazer isso visitando seu site e usando as ferramentas de desenvolvedor do seu navegador para verificar os cabeçalhos de resposta. Você deve ver o cabeçalho Strict-Transport-Security com o valor definido.
  2. Considere adicionar seu site à lista de pré-carregamento do HSTS: a lista de pré-carregamento HSTS é uma lista de sites que são codificados em navegadores como habilitados para HSTS. Isso fornece um nível extra de proteção, pois garante que a primeira conexão com seu site seja segura, mesmo antes do recebimento do cabeçalho HSTS. Você pode enviar seu site para a lista de pré-carregamento do HSTS em hstspreload.org.

 

Caso de uso: um site de notícias deseja garantir que seus usuários sempre se conectem a ele com segurança, mesmo que digitem acidentalmente "http" em vez de "https" no URL. O site usa HSTS adicionando o cabeçalho Strict-Transport-Security à configuração do servidor, definindo uma idade máxima longa e incluindo todos os subdomínios. Isso informa aos agentes do usuário para sempre se conectarem a ele usando HTTPS, protegendo os usuários de ataques que tentam fazer o downgrade da conexão para HTTP e roubar seus cookies. O site também se submete à lista de pré-carregamento HSTS para proteção extra.

Implementar fixação de chave pública HTTP (HPKP)

HTTP Public Key Pinning (HPKP) era um recurso de segurança que permitia que um servidor da Web associasse uma chave pública criptográfica específica a si mesmo para evitar ataques man-in-the-middle (MITM) com certificados forjados.

Aqui está uma breve visão geral de como foi usado:

  1. Gerar informações de fixação: A primeira etapa na implementação do HPKP foi gerar as informações de fixação. Isso envolvia a criação de um hash criptográfico da chave pública do certificado ou da chave pública do certificado intermediário ou raiz.
  2. Configurar o servidor Web: A próxima etapa foi configurar o servidor web para incluir o HTTP de pinos de chave pública cabeçalho nas respostas. Esse cabeçalho incluía os hashes das chaves públicas (os “pins”), um tempo de vida (por quanto tempo o navegador deve lembrar as informações) e, opcionalmente, um URI de relatório (onde o navegador enviaria relatórios de falhas de validação de pinos).
  3. Lidar com falhas de validação de pinos: se um navegador compatível com HPKP recebesse uma cadeia de certificados que não incluísse pelo menos uma das chaves públicas fixadas, ele consideraria a conexão não confiável. Se um URI de relatório fosse especificado, o navegador também enviaria um relatório da falha para esse URI.

 

No entanto, devido ao risco de uso indevido e ao potencial de causar negação de serviço, o HPKP foi preterido pela maioria dos navegadores e não é mais uma prática recomendada. A configuração incorreta do HPKP pode levar a uma situação em que um site se torna inacessível.

Caso de uso: no passado, uma empresa de tecnologia usava o HPKP para fixar suas chaves públicas em seus servidores. Isso garantiu que, se uma autoridade de certificação (CA) fosse comprometida e um certificado fosse emitido por engano para seu domínio, os navegadores não confiariam nela, a menos que ela também tivesse uma chave pública que correspondesse a uma das chaves fixadas. No entanto, eles precisavam ter muito cuidado para não perder o acesso às chaves fixadas, o que tornaria o site inacessível. Eles também tiveram que garantir que tivessem um processo para girar os pinos antes que eles expirassem, para evitar tornar seu site inacessível para usuários com informações de pinos em cache.

SSL.com fornece uma ampla variedade de SSL/TLS certificados do servidor. Proteja seu site hoje com um certificado SSL da SSL.com e construir confiança com seus visitantes!

COMPARAR SSL /TLS CERTIFICADOS

Use TLS Fallback SCSV para evitar ataques de downgrade de protocolo

TLS Substituição SCSV (Valor do Conjunto de Cifras de Sinalização) é um mecanismo que foi introduzido para evitar ataques de downgrade de protocolo. Esses ataques ocorrem quando um invasor interfere no processo de configuração da conexão e induz o cliente e o servidor a usar uma versão menos segura do protocolo do que ambos realmente suportam.

Veja como você pode implementar TLS SCSV alternativo:

  1. Atualize o SSL do seu servidor/TLS Library: A primeira etapa é garantir que o SSL/TLS suportes de biblioteca TLS SCSV alternativo. Este recurso foi introduzido no OpenSSL 1.0.1j, 1.0.0o e 0.9.8zc. Se você estiver usando um SSL/TLS biblioteca, verifique sua documentação ou entre em contato com seus desenvolvedores.
  2. Configure o seu servidor: Assim que o SSL/TLS suportes de biblioteca TLS Fallback SCSV, pode ser necessário configurar seu servidor para usá-lo. As etapas exatas dependerão do software do servidor. Por exemplo, no Apache, você pode precisar adicionar ou modificar uma linha em seu arquivo de configuração como esta:

 

Protocolo SSL Todos -SSLv2 -SSLv3

Esta linha informa ao servidor para usar todas as versões de protocolo, exceto SSLv2 e SSLv3. Se o cliente e o servidor suportarem TLS 1.2, mas o cliente tenta usar TLS 1.1 (talvez devido à interferência de um invasor), o servidor reconhecerá isso como uma tentativa de fallback e rejeitará a conexão.

  1. Teste seu servidor: Depois de configurar seu servidor, você deve testá-lo para garantir que está implementando corretamente TLS SCSV alternativo. Existem várias ferramentas online que podem ajudá-lo com isso, como o SSL Labs Server Test.

 

Caso de uso: Uma corporação global usa TLS Fallback SCSV para proteger suas comunicações internas. Isso garante que, se um invasor tentar forçar um downgrade de protocolo, o servidor reconhecerá isso e rejeitará a conexão, protegendo os dados confidenciais da corporação. A equipe de TI da corporação atualiza regularmente o SSL/TLS bibliotecas e configurações para garantir que estão usando os recursos de segurança mais recentes e usam ferramentas online para testar seus servidores e confirmar que estão implementando corretamente TLS SCSV alternativo.

Evite problemas de conteúdo misto

O conteúdo misto é um risco de segurança que ocorre quando uma página da Web carregada por uma conexão HTTPS segura inclui recursos, como imagens, vídeos, folhas de estilo ou scripts, que são carregados por uma conexão HTTP insegura. Os navegadores podem bloquear esse conteúdo misto ou exibir um aviso ao usuário, o que pode prejudicar a percepção do usuário sobre a segurança do site.

Veja como você pode evitar problemas de conteúdo misto:

  1. Use HTTPS para todos os recursos: a maneira mais direta de evitar conteúdo misto é garantir que todos os recursos do seu site sejam carregados por HTTPS. Isso inclui imagens, scripts, folhas de estilo, iframes, solicitações AJAX e quaisquer outros recursos que seu site usa.
  2. Atualize o código do seu site: se o código do seu site incluir URLs HTTP codificados para recursos, você precisará atualizá-los para usar HTTPS. Se o recurso estiver hospedado em um servidor que não oferece suporte a HTTPS, talvez seja necessário hospedar o recurso em seu próprio servidor ou encontrar um recurso alternativo que possa ser carregado por HTTPS.
  3. Configure seu servidor para enviar um cabeçalho de política de segurança de conteúdo: o cabeçalho HTTP Content-Security-Policy (CSP) permite que você controle quais recursos seu site pode carregar. Ao definir um cabeçalho CSP que permite apenas recursos HTTPS, você pode garantir que seu site não inclua acidentalmente conteúdo misto.

 

Caso de uso: uma revista on-line garante que todo o conteúdo, incluindo imagens e scripts, seja carregado por HTTPS. Isso evita que invasores adulterem esses recursos e injetem conteúdo malicioso. Os desenvolvedores da web da revista revisam regularmente o código do site para garantir que todos os recursos sejam carregados por HTTPS e configuram seu servidor para enviar um cabeçalho restrito de política de segurança de conteúdo. Eles também usam ferramentas on-line para escanear o site em busca de problemas de conteúdo misto e corrigir os que encontrarem.

Utilize a indicação do nome do servidor (SNI) para hospedar vários sites

Indicação de nome de servidor (SNI) é uma extensão do TLS protocolo que permite que um servidor apresente vários certificados no mesmo endereço IP e número de porta. Isso é particularmente útil para provedores de hospedagem na web que precisam hospedar vários sites seguros, cada um com seu próprio certificado SSL, no mesmo servidor.

Veja como você pode usar o SNI:

  1. Certifique-se de que seu software de servidor suporte SNI: A primeira etapa é garantir que o software do servidor suporte SNI. A maioria dos servidores Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a SNI.
  2. Configure o seu servidor: A próxima etapa é configurar seu servidor para usar SNI. Isso normalmente envolve adicionar um bloco de configuração separado para cada site que você deseja hospedar no servidor e especificar o Certificado SSL usar para cada site. As etapas exatas dependerão do software do servidor.
  3. Teste sua configuração: Depois de configurar seu servidor, você deve testá-lo para garantir que está usando o SNI corretamente. Você pode fazer isso visitando cada site que está hospedando no servidor e verificando se o certificado SSL correto está sendo usado.

 

Caso de uso: um provedor de hospedagem usa SNI para atender vários sites do mesmo endereço IP. Isso permite que eles usem com eficiência seu espaço de endereço IP e simplifiquem sua configuração de rede. Eles configuram seu servidor para usar um certificado SSL diferente para cada site e testam regularmente sua configuração para garantir que o certificado correto esteja sendo usado para cada site. Isso garante que cada site tenha uma conexão segura e confiável, mesmo que todos estejam sendo atendidos pelo mesmo endereço IP.

Otimize o desempenho com a retomada da sessão

A retomada da sessão é um recurso do TLS protocolo que permite que um cliente e um servidor usem as mesmas chaves de criptografia em várias sessões, reduzindo a sobrecarga de estabelecer uma nova conexão segura a cada vez. Isso pode melhorar significativamente o desempenho, especialmente para aplicativos em que o cliente se desconecta e reconecta com frequência.

 Veja como você pode usar a retomada de sessão:

  1. Certifique-se de que o software do seu servidor suporte a retomada da sessão: a primeira etapa é garantir que o software do servidor ofereça suporte à retomada da sessão. A maioria dos servidores da Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: A próxima etapa é configurar seu servidor para usar a retomada de sessão. Isso geralmente envolve habilitar o cache de sessão e definir um valor de tempo limite para o cache. As etapas exatas dependerão do software do servidor.
  3. Teste sua configuração: Depois de configurar seu servidor, você deve testá-lo para garantir que ele esteja usando a retomada de sessão corretamente. Você pode fazer isso estabelecendo um TLS conexão com seu servidor, desconectando e reconectando. Se a retomada da sessão estiver funcionando corretamente, a segunda conexão deve ser mais rápida de estabelecer do que a primeira.

 

Caso de uso: um aplicativo móvel usa a retomada de sessão para manter conexões rápidas e seguras. Isso é particularmente útil quando o aplicativo é usado em áreas com cobertura de rede irregular, pois permite que o aplicativo restabeleça rapidamente uma conexão segura após uma interrupção. Os desenvolvedores do aplicativo configuram seu servidor para usar a retomada de sessão e testam regularmente o recurso para garantir que esteja funcionando corretamente. Isso garante que o aplicativo possa fornecer uma experiência rápida e perfeita para os usuários, mesmo em condições de rede desafiadoras.

 

Garanta a validade do certificado com grampeamento OCSP

O grampeamento do Online Certificate Status Protocol (OCSP) é um método para melhorar o desempenho de SSL/TLS mantendo a segurança da conexão. Ele permite que o servidor busque o status atual de seus próprios certificados da Autoridade de Certificação (CA) e, em seguida, entregue esse status aos clientes durante o TLS aperto de mão.

Veja como você pode implementar o grampeamento OCSP:

  1. Certifique-se de que seu software de servidor suporte grampeamento OCSP: a primeira etapa é garantir que o software do servidor ofereça suporte ao grampeamento OCSP. A maioria dos servidores Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: a próxima etapa é configurar seu servidor para usar o grampeamento OCSP. Isso normalmente envolve habilitar o recurso no SSL/TLS configuração e especificando um local para o servidor armazenar as respostas OCSP. As etapas exatas dependerão do software do servidor.
  3. Teste sua configuração: Depois de configurar seu servidor, você deve testá-lo para garantir que esteja usando grampeamento OCSP corretamente. Você pode fazer isso estabelecendo um TLS conexão com seu servidor e verificando se o servidor inclui uma resposta OCSP no TLS aperto de mão.

 

Caso de uso: um varejista on-line usa grampeamento OCSP para verificar rapidamente o status de seu certificado SSL. Isso garante que os clientes sempre tenham uma conexão segura e possam confiar que seus dados estão seguros. A equipe de TI do varejista configura seu servidor para usar o grampeamento OCSP e testa regularmente o recurso para garantir que esteja funcionando corretamente. Isso ajuda a manter a confiança de seus clientes e proteger seus dados confidenciais.

 

Desabilitar TLS Compressão para Mitigar Ataque CRIME

TLS compactação é um recurso que pode melhorar o desempenho de SSL/TLS reduzindo a quantidade de dados que precisam ser enviados pela rede. No entanto, também pode tornar a conexão vulnerável ao ataque CRIME (Compression Ratio Info-leak Made Easy), que pode permitir que um invasor infira o conteúdo do tráfego criptografado.

Veja como você pode desativar TLS compressão: 

  1. Verifique se o software do servidor oferece suporte à desativação TLS Compressão: A primeira etapa é garantir que o software do servidor suporte a desativação TLS compressão. A maioria dos servidores da Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: O próximo passo é configurar seu servidor para desabilitar TLS compressão. As etapas exatas dependerão do software do servidor. Por exemplo, no Apache, você pode adicionar uma linha como esta ao seu arquivo de configuração:
SSLCompression desativado

Esta linha diz ao servidor para não usar compactação para SSL/TLS conexões.

  1. Teste sua configuração: Depois de configurar seu servidor, você deve testá-lo para garantir que está desabilitando corretamente TLS compressão. Você pode fazer isso estabelecendo um TLS conexão com seu servidor e verificando se a conexão não está usando compressão.

 

Caso de uso: Uma instituição financeira desativa TLS compactação em seus servidores para proteção contra o ataque CRIME. Isso ajuda a garantir a confidencialidade de dados financeiros confidenciais, como números de contas e detalhes de transações. A equipe de TI da instituição configura seus servidores para desabilitar TLS compactação e eles testam regularmente os servidores para garantir que estão implementando corretamente essa medida de segurança. Isso ajuda a proteger os clientes da instituição e manter sua confiança.

Executar TLS Tíquetes de Sessão Corretamente

TLS os bilhetes de sessão são uma característica do TLS protocolo que pode melhorar o desempenho, permitindo que um cliente e um servidor retomem uma sessão anterior sem a necessidade de realizar um handshake completo. No entanto, eles precisam ser implementados corretamente para evitar possíveis problemas de segurança.

Veja como você pode implementar corretamente TLS bilhetes de sessão:

  1. Certifique-se de que seu software de servidor suporte TLS Tíquetes de Sessão: A primeira etapa é garantir que o software do servidor suporte TLS bilhetes de sessão. A maioria dos servidores da Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: O próximo passo é configurar seu servidor para usar TLS bilhetes de sessão. Isso normalmente envolve habilitar o recurso no SSL/TLS configuração. As etapas exatas dependerão do software do servidor.
  3. Use Chaves de Tíquete de Sessão Exclusivas: Para evitar possíveis problemas de segurança, cada servidor deve usar uma chave de tíquete de sessão exclusiva. Se estiver usando um balanceador de carga, você deve configurá-lo para distribuir clientes com base em seu tíquete de sessão, em vez de permitir que os clientes usem um tíquete de sessão emitido por um servidor para estabelecer uma sessão com outro servidor.
  4. Alterne as Chaves do Tíquete de Sessão Regularmente: para aumentar ainda mais a segurança, você deve alternar regularmente as chaves do tíquete de sessão. Muitas vezes, isso pode ser automatizado usando o software do servidor ou um sistema de gerenciamento de chaves separado.

 

Caso de uso: uma grande empresa de tecnologia com vários servidores garante que cada servidor use uma chave de tíquete de sessão exclusiva. Isso impede que um invasor use um tíquete de sessão de um servidor para representar um usuário em outro servidor. A equipe de TI da empresa configura seus servidores para usar TLS tíquetes de sessão e eles configuram um sistema para alternar regularmente as chaves do tíquete de sessão. Eles também configuram seu balanceador de carga para distribuir clientes com base em seu tíquete de sessão, aumentando ainda mais a segurança de seu sistema.

Ativar renegociação segura

A renegociação segura é um recurso do SSL/TLS protocolos que permitem ao cliente ou servidor solicitar um novo TLS aperto de mão no meio de uma sessão. Isso pode ser útil por vários motivos, como atualizar as chaves de criptografia ou alterar o nível de criptografia. No entanto, se não for tratado com segurança, pode ser explorado por um invasor para injetar texto sem formatação na comunicação criptografada.

Veja como você pode habilitar a renegociação segura:

  1. Certifique-se de que o software do seu servidor oferece suporte à renegociação segura: a primeira etapa é garantir que o software do servidor ofereça suporte à renegociação segura. A maioria dos servidores Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: A próxima etapa é configurar seu servidor para usar a renegociação segura. Isso normalmente envolve habilitar o recurso no SSL/TLS configuração. As etapas exatas dependerão do software do servidor.
  3. Teste sua configuração: Depois de configurar seu servidor, você deve testá-lo para garantir que esteja usando corretamente a renegociação segura. Você pode fazer isso estabelecendo um TLS conexão com seu servidor e, em seguida, tentar renegociar a conexão.

 

Caso de uso: uma plataforma de mídia social permite uma renegociação segura para proteger os dados do usuário. Isso evita que um invasor consiga injetar conteúdo malicioso na comunicação criptografada entre o usuário e o servidor. A equipe de TI da plataforma configura seus servidores para usar renegociação segura e testa regularmente os servidores para garantir que estão implementando corretamente essa medida de segurança. Isso ajuda a proteger os usuários da plataforma e manter sua confiança.

Desative a renegociação iniciada pelo cliente para evitar ataques DoS

A renegociação iniciada pelo cliente é um recurso do SSL/TLS protocolos que permitem ao cliente solicitar um novo TLS aperto de mão no meio de uma sessão. No entanto, se um invasor puder forçar um servidor a renegociar continuamente as sessões, poderá consumir recursos excessivos e potencialmente levar a um ataque de negação de serviço (DoS).

Veja como você pode desabilitar a renegociação iniciada pelo cliente:

  1. Certifique-se de que o software do servidor suporte a desativação da renegociação iniciada pelo cliente: a primeira etapa é garantir que o software do servidor suporte a desativação da renegociação iniciada pelo cliente. A maioria dos servidores Web modernos, incluindo Apache, Nginx e IIS, oferece suporte a esse recurso.
  2. Configure o seu servidor: A próxima etapa é configurar seu servidor para desabilitar a renegociação iniciada pelo cliente. Isso normalmente envolve adicionar uma diretiva ao SSL/TLS configuração. As etapas exatas dependerão do software do servidor.
  3. Teste sua configuração: depois de configurar seu servidor, você deve testá-lo para garantir que ele esteja desabilitando corretamente a renegociação iniciada pelo cliente. Você pode fazer isso estabelecendo um TLS conexão com seu servidor e, em seguida, tentar renegociar a conexão. Se o servidor recusar corretamente a solicitação de renegociação, ele está configurado corretamente.

 

Caso de uso: uma plataforma de jogos online desativa a renegociação iniciada pelo cliente para proteger contra possíveis ataques DoS. Isso ajuda a garantir que a plataforma permaneça disponível para os usuários aproveitarem, mesmo diante de possíveis ataques. A equipe de TI da plataforma configura seus servidores para desabilitar a renegociação iniciada pelo cliente e testa regularmente os servidores para garantir que estão implementando corretamente essa medida de segurança. Isso ajuda a proteger os usuários da plataforma e manter sua confiança.

Fique alerta para novas vulnerabilidades

A segurança da Web é um alvo em constante movimento e você sempre deve estar atento ao próximo ataque e aplicar prontamente patches de segurança no servidor. Isso significa ler e ficar em contato com o que está por vir quando se trata de segurança da informação, bem como manter o controle das atualizações de software - especialmente as críticas. Site SSL.com (onde você está lendo isso agora) é uma ótima fonte para se manter atualizado sobre SSL /TLS e segurança da informação.

Mas e quanto ...?

Se quiser saber mais sobre qualquer um dos tópicos abordados neste guia e aprender sobre novos problemas e tecnologias à medida que surgem, você pode começar navegando e pesquisando no SSL.com Base de Conhecimento, que mantemos atualizados semanalmente com novos desenvolvimentos na área de SSL /TLS e PKI. Você também pode entrar em contato com nossa equipe de suporte a qualquer momento, via e-mail em Support@SSL.com, no telefone em 1-877-SSL-Secureou clicando no link de bate-papo no canto inferior direito desta página.

SSL.com oferece uma grande variedade de SSL /TLS certificados de servidor para sites HTTPS.

COMPARAR SSL /TLS CERTIFICADOS

 

Obtenha conselhos de especialistas sobre certificados SSL.
Preencha o formulário para uma consulta.

Twitter
Facebook
LinkedIn
Reddit
E-mail

Mantenha-se informado e seguro

SSL.com é líder global em segurança cibernética, PKI e certificados digitais. Inscreva-se para receber as últimas notícias do setor, dicas e anúncios de produtos da SSL.com.

Adoraríamos receber seu feedback

Responda à nossa pesquisa e deixe-nos saber sua opinião sobre sua compra recente.