TLS Security

Identificação, Análise, Vulnerabilidades, Hardening

TLS Security 1: O que é SSL/TLS

A Secure Sockets Layer (SSL) e a Transport Layer Security (TLS) são protocolos de segurança criptográfica. Eles são usados para garantir que a comunicação de rede seja segura. Seus principais objetivos são fornecer integridade de dados e privacidade de comunicação. O protocolo SSL foi o primeiro protocolo projetado para este fim e o TLS é seu sucessor. O SSL agora é considerado obsoleto e inseguro (até mesmo sua versão mais recente), então navegadores modernos como Chrome ou Firefox usam TLS em vez disso.

SSL e TLS são comumente usados por navegadores da Web para proteger conexões entre aplicativos web e servidores web. Muitos outros protocolos baseados em TCP também usam TLS/SSL, incluindo e-mail (SMTP/POP3), mensagens instantâneas (XMPP), FTP, VoIP, VPN e outros. Normalmente, quando um serviço usa uma conexão segura, a letra S é anexada ao nome do protocolo, por exemplo, HTTPS, SMTPS,FTPS,SIPS. Na maioria dos casos, as implementações SSL/TLS são baseadas na biblioteca OpenSSL.

SSL e TLS são estruturas que usam muitos algoritmos criptográficos diferentes,por exemplo, RSA e vários algoritmos Diffie-Hellman. As partes concordam em qual algoritmo usar durante a comunicação inicial. A versão mais recente do TLS (TLS 1.3) está especificada no documento IETF (Internet Engineering Task Force) RFC 8446 e a versão SSL mais recente (SSL 3.0) está especificada no documento IETF RFC 6101.

Privacidade e integridade

Os protocolos SSL/TLS permitem que a conexão entre dois meios (cliente-servidor) seja criptografada. A criptografia permite que você certifique-se de que nenhum terceiro seja capaz de ler os dados ou adulterá-los. A comunicação não criptografada pode expor dados confidenciais, como nomes de usuários, senhas, números de cartão de crédito e muito mais. Se usarmos uma conexão não criptografada e um terceiro interceptar nossa conexão com o servidor, eles podem ver todas as informações trocadas em texto simples. Por exemplo, se acessarmos o painel de administração do site sem SSL, e um invasor estiver farejando o tráfego de rede local, eles verão as seguintes informações.

O cookie que usamos para autenticar em nosso site é enviado em texto simples e qualquer um que intercepte a conexão pode vê-lo. O invasor pode usar essas informações para entrar no nosso painel de administração do site. A partir daí, as opções do atacante se expandem dramaticamente. No entanto, se acessarmos nosso site usando SSL/TLS, o invasor que está farejando tráfego verá algo bem diferente.

Neste caso, a informação é inútil para o agressor.

Identificação

Os protocolos SSL/TLS usam criptografia de chave pública. Com exceção da criptografia, essa tecnologia também é usada para autenticar partes comunicantes. Isso significa que uma ou ambas as partes sabem exatamente com quem estão se comunicando. Isso é crucial para aplicações como transações online, porque deve ter certeza de que estamos transferindo dinheiro para a pessoa ou empresa que é quem eles afirmam ser.

Quando uma conexão segura é estabelecida, o servidor envia seu certificado SSL/TSL ao cliente. O certificado é então verificado pelo cliente contra uma Autoridade de Certificado confiável, validando a identidade do servidor. Tal certificado não pode ser falsificado, então o cliente pode ter cem por cento de certeza de que está se comunicando com o servidor certo.

Perfect Forward Secrecy

O perfect forward secrecy (PFS) é um mecanismo que é usado para proteger o cliente se a chave privada do servidor estiver comprometida. Graças ao PFS, o invasor não é capaz de descriptografar qualquer comunicação TLS anterior. Para garantir o sigilo perfeito para a frente, usamos novas chaves para cada sessão. Essas chaves são válidas apenas enquanto a sessão estiver ativa.

TLS Security 2: Uma breve história do SSL/TLS

O protocolo Secure Sockets Layer (SSL) foi introduzido pela primeira vez pela Netscape em 1994. A Internet estava crescendo e havia a necessidade de segurança de transporte para navegadores web e para vários protocolos TCP. A versão 1.0 do SSL nunca foi lançada porque tinha sérias falhas de segurança. O primeiro lançamento oficial do SSL, versão 2.0, saiu em 1995. A versão final do protocolo SSL, SSL 3.0, foi lançada em novembro de 1996.

Em 2011, a Força-Tarefa de Engenharia da Internet (IETF) anunciou que a versão 2.0 do SSL está preterida. O IETF recomendou que o SSL v2 fosse completamente abandonado porque, de acordo com um documento que eles lançaram(RFC 6176), o protocolo tem várias deficiências importantes. Estes incluíram o uso de MD5 para autenticação de mensagens, falta de proteção para apertos de mão, uso da mesma chave para integridade e criptografia de mensagens e fácil término da sessão. Em junho de 2015, a IETF também anunciou que o SSL 3.0 está preterido. Como indicado em um documento divulgado pelo IETF (RFC 7568),qualquer versão TLS é mais segura do que todas as versões do SSL. O SSL também não pode usar recursos do protocolo TLS, como criptografia autenticada com dados adicionais (AEAD), Diffie-Hellman da Curva Elíptica (ECDH) e Algoritmo de Assinatura Digital da Curva Elíptica (ECDSA), bilhetes de sessão sem estado, um modo de operação de datagrama (DTLS) e negociação de protocolo de camada de aplicativo.

TLS para o Resgate

TLS – Transport Layer Security, certifica a proteção de dados de maneira semelhante ao SSL.

Quando você instala um certificado SSL/TLS a transmissão de dados é configurada para ser feita via HTTPS. Ambas as tecnologias andam de mãos dadas e não funcionam uma sem a outra.

O servidor envia e o cliente sabe quem é

O servidor não se preocupa em verificar a identidade do cliente.

A falta do certificado, inclusive, pode representar perda de posição em motores de busca.

No coração do TLS está a Public Key Infrastructure (PKI) e, em particular, os certificados X.509.

O protocolo TLS (Transport Layer Security, segurança da camada de transporte) foi introduzido pela primeira vez em 1999 como um upgrade para o SSL v3. O documento TLS 1.0 RFC (RFC 2246) afirma que as diferenças entre o TLS 1.0 e o SSL 3.0 não são dramáticas, mas são significativas o suficiente para impedir a interoperabilidade. TLS 1.1 (RFC 4346) foi uma pequena atualização para o TLS 1.0 lançado em abril de 2006. Algumas das diferenças nesta versão incluíram proteções contra ataques cbc (Cipher Block Chaining, chaining de blocos de cifras). TLS 1.2 (RFC 5246) foi lançado em agosto de 2008. As alterações incluíram a adição de funções de pseudorandom especificadas por suítes cifradas (PRFs), a adição de suítes cifradas AES, a remoção de suítes de cifras IDEA e DES e vários outros aprimoramentos.

A versão atual do TLS, TLS 1.3, foi lançada em agosto de 2018 (RFC 8446). O IETF levou 10 anos e 28 rascunhos para ser concluído. Desta vez, o protocolo sofreu algumas grandes mudanças com o foco na simplicidade. Várias tecnologias inseguras foram removidas, incluindo SHA-1, MD5, RC4, DES e 3DES. O protocolo foi simplificado para melhor desempenho: o aperto de mão agora requer apenas uma ida e volta (em alguns casos até zero). Outras mudanças incluem criptografia de informações SNI para melhor privacidade e um novo padrão de assinatura (RSA-PSS). Todos os navegadores modernos suportam O TLS v1.3.

TLS Security 3: Terminologia e Noções Básicas SSL/TLS

Para entender como funcionam os protocolos TLS (Transport Layer Security, segurança da camada de camada de tomadas seguras) e de camada de soquetes seguros (SSL), você deve primeiro entender certos conceitos básicos. O mecanismo primário usado pelo SSL/TLS é a criptografia assimétrica com suítes cifradas. Estes e os termos relacionados são explicados abaixo.

Criptografia

A criptografia é o processo em que uma mensagem legível pelo homem (plaintext) é convertida em um formato criptografado, não-humano-legível (textocifrado). O principal objetivo da criptografia é garantir que apenas um destinatário autorizado seja capaz de descriptografar e ler a mensagem original. Quando dados não criptografados são trocados entre duas partes, usando qualquer meio, um terceiro pode interceptar e ler a comunicação trocada.

Se a troca contiver informações confidenciais, isso implica perda de confidencialidade. Além disso, se o terceiro puder interceptar e ler as mensagens, eles podem adulterar os dados. Isso significa que eles podem alterar as informações que estão sendo trocadas, por isso compromete a integridade da mensagem.

Imagine enviar um pagamento usando uma conexão de navegador da Web não criptografada. O pagamento inclui os dados da sua conta bancária, bem como o valor que você autorizou. Um invasor poderia usar um ataque homem no meio para adulterar as informações enviadas ao servidor web e alterar o valor de US $ 100 para US $ 10.000. O banco recebe dados adulterados de terceiros em vez de você, o que significa que não há autenticidade. Se você usar uma sessão segura criptografada, um invasor ainda pode ser capaz de interceptar o tráfego, mas eles não serão capazes de ler os dados ou adulterá-los.

Criptografia simétrica

A criptografia simétrica é o processo no qual a mesma chave é usada para criptografar e descriptografia de dados. Se Thomas quiser enviar informações para Bob, ele usará uma chave compartilhada para criptografar os dados e Bob descriptografará os dados usando a mesma chave.

O maior problema com a criptografia de chave simétrica é que ambas as partes que trocam dados devem ter a chave compartilhada. Se essa chave compartilhada for exposta, um invasor poderá descriptografar toda a comunicação criptografada usando essa chave. É por isso que a chave compartilhada deve ser distribuída entre as partes usando um canal de comunicação já estabelecido, seguro e criptografado. Outra desvantagem da criptografia simétrica é que você não pode autenticar o remetente de uma mensagem, o que compromete a autenticidade.

Vantagens da criptografia simétrica:

• Uso rápido e baixo de recursos
• Operação simples
• Seguro

Desvantagens da criptografia simétrica:

• Mesma chave usada para criptografia/descriptografia
• A chave deve ser distribuída usando um canal seguro já estabelecido
• Chave diferente para diferentes partes – difícil gerenciamento/distribuição de chaves
• Não é possível autenticar usuários

Criptografia assimétrica

A criptografia assimétrica (também conhecida como criptografia de chave pública) usapares-chave: uma chave pública e uma chave privada. Essas chaves criptográficas estão exclusivamente relacionadas. Isso significa que o conteúdo criptografado usando uma chave do par de chaves só pode ser descriptografado usando o outro. A chave pública, como o nome indica, pode ser compartilhada com qualquer um. A chave privada deve ser conhecida apenas pelo proprietário.

Você também pode usar criptografia assimétrica para autenticar o remetente assinando. Se Bob assinar uma mensagem usando sua chave privada, quem verificar a assinatura usando a chave pública de Bob pode ter certeza de que Bob é o remetente.

Vantagens da criptografia assimétrica:

• Distribuição de chaves é fácil
• Autenticidade
• Integridade
• Segurança

Desvantagens da criptografia assimétrica:

• Mais lento que a criptografia simétrica
• Precisa de mais recursos

Cifras

Cifras são métodos/algoritmos usados para criptografar e descriptografar dados. TLS é um protocolo que permite que você use muitos métodos/algoritmos diferentes. Eles são fornecidos como pacotes chamados suítes cifradas. Tal pacote tem um método/algoritmo diferente para cada tarefa.

Cifras de blocos

Se você usar uma cifra de bloco, os dados ão são divididos em blocos de comprimento fixo (por exemplo, blocos de 64 bits ou 128 bits) e, em seguida, criptografados. Se o último bloco de dados for menor do que o comprimento do bloco especificado, o algoritmo usará preenchimento para preencher o espaço vazio. Os blocos geralmente são acolchos usando dados aleatórios. As cifras de blocos populares incluem AES, Blowfish, 3DES, DES e RC5.

Preenchimento

As cifras de bloco têm um comprimento fixo especificado e a maioria delas exige que os dados de entrada sejam múltiplos de seu tamanho. É comum que o último bloco contenha dados que não atendam a essa exigência. Neste caso, o preenchimento (geralmente dados aleatórios) é usado para levá-lo ao comprimento do bloco necessário.

Vetor de inicialização (IV)

Um vetor de inicialização é uma entrada aleatória (ou pseudorandom) de tamanho fixo usada em métodos de criptografia. O objetivo principal de uma intravenosa é iniciar um método de criptografia. Em modos cifrados como Cipher Block Chaining (CBC) cada bloco é XOR-ed com o bloco anterior. No primeiro bloco, não há bloco anterior para XOR com. Um vetor de inicialização é usado como uma entrada para o primeiro bloco para iniciar o processo.

Se IV é único para cada mensagem, é chamado de nonce, o que significa que ela só pode ser usada uma vez. Uma nonce deve ser imprevisível. Ele também é usado para evitar que os atacantes descriptografem todas as mensagens adivinhando a intravenosa. Se você usar um nonce, o mesmo texto simples pode ser criptografado usando a mesma chave em texto de cifra diferente.

Modos de operação de cifra de bloco

O modo de operação da cifra de bloco define as relações entre blocos codificados usando a cifra. Existem diferentes modos que foram criados para tornar mais difícil para um invasor adivinhar o conteúdo original da mensagem.

Livro de Códigos Eletrônicos (BCE)

Ao usar o BCE, cada bloco de dados é criptografado separadamente e eles são então concatenados na ordem original. O processamento paralelo é possível, já que os blocos não dependem um do outro. Não há necessidade de uma intravenosa. O grande problema do BCE é que, se o mesmo bloco de dados for criptografado, ele sempre gerará o mesmo texto cifrado. Isso torna mais fácil para o invasor adivinhar os dados originais com base em padrões repetitivos.

Cipher Block Chaining (CBC)

Ao usar o CBC, cada bloco é XORed com o texto cifrado anterior antes da criptografia. Isso elimina o problema de repetir padrões. Uma intravenosa é necessária para criptografar o primeiro bloco de texto simples. O processamento paralelo não é possível, uma vez que os blocos estão acorrentados. Há uma grande desvantagem da CBC: se parte da mensagem está embaralhada ou perdida, o restante da mensagem é perdida.

Cipher Feedback (CFB)

O método CFB transforma uma cifra de bloco em uma cifra de fluxo auto-sincronizante. Isso significa que se parte da mensagem estiver embaralhada ou perdida, a cifra pode sincronizar após vários blocos e o restante da mensagem não é necessariamente perdido.

Feedback de saída (OFB)

O método OFB cria uma cifra de fluxo síncrocro. Esta técnica preserva códigos de correção de erros. Os processos de criptografia e descriptografia são exatamente os mesmos.

Modo contador (CTR)

O método CTR é semelhante ao OFB, pois também cria uma cifra de fluxo síncrocro. No entanto, ele usa um contador e uma nonce para cada bloco e não liga os blocos juntos. Portanto, os blocos podem ser criptografados e descriptografados em paralelo.

Cifras de córregos

As cifras de fluxo criptografam dados um bit ou byte de cada vez. Cada bit é criptografado com uma chave diferente. Cifras de fluxo não são usadas frequentemente na criptografia moderna. Um exemplo popular de uma cifra de fluxo é a cifra RC4.

Código de autenticação de mensagens (MAC)

O código de autenticação de mensagem (MAC) é um método usado para verificar a autenticidade, bem como a integridade de uma mensagem. Ele aceita dois parâmetros de entrada: uma chave secreta e uma mensagem de comprimento arbitrário. O resultado é chamado de tag. O destinatário também tem a chave secreta e pode usá-la para detectar quaisquer alterações no conteúdo da mensagem. O MAC às vezes é chamado de checksum, cryptographic checksumou checkum protegido.

Se a tag MAC do remetente e a tag MAC calculada do destinatário corresponder, ninguém adulterou a mensagem. Se eles não corresponderem, alguém alterou a mensagem durante a transmissão.

Código de autenticação de mensagens baseado em hash (HMAC)

HMAC é um tipo de MAC que usa uma função hash. A seguir, um exemplo de HMAC que usa o algoritmo de hash SHA256.

HMAC_SHA256(“s3cr3tk3y”,”Hello World”= 2d9615ee921dab63c7c4c839842703fe338db46fdf17593a681bcee2c52721de

A ilustração a seguir mostra como funciona a função HMAC:

TLS Security 4: Certificados SSL/TLS

Quando você se comunica com segurança com um terceiro usando criptografia de dados, você geralmente quer ter certeza de que eles são quem eles dizem que são. Por exemplo, quando você usa um banco online ou um site de comércio eletrônico e envia informações confidenciais, você quer ter certeza de que este não é um site impostor.

Para isso, o protocolo SSL (Secure Sockets Layer) e o protocolo TLS (Transport Layer Security) incluem uma medida de segurança chamada certificados digitais. Usando esse mecanismo, uma chave pública pode ser assinada por outra parte. Um certificado também contém informações de identidade relativas ao proprietário da chave pública.

Autoridades de Certificado

Se você visitar o site de um banco e receber um certificado que é assinado por outra entidade, você ainda pode se sentir incerto sobre a segurança do site. Você pode estar preocupado que a entidade que assinou o certificado seja um impostor. Esse problema é resolvido pela Infraestrutura de Chaves Públicas (PKI). O PKI inclui tudo o que é necessário para gerenciar certificados digitais e criptografia de chaves públicas.

Existem várias entidades PKI em que você pode confiar. Eles são chamados de Autoridades de Certificado (CAs). Eles verificam outras entidades (empresas, organizações, indivíduos) e confirmam que são de fato quem dizem ser. Após tal verificação, um CA assina o certificado usando seu próprio certificado. O certificado de ca é chamado de certificado raiz.

Os certificados raiz de todos os CAs (e, portanto, suas chaves públicas) são considerados confiáveis. Eles estão instalados em todos os navegadores, como Chrome, Firefox e Edge e em sistemas operacionais (incluindo Windows). Os CAs populares incluem IdenTrust, Comodo, DigiCert, GoDaddy, GlobalSign e Symantec. Atualmente, existem mais de 200 certificados raiz que são confiáveis pelos navegadores.

Uma conexão web SSL/TLS requer um certificado TLS/SSL, mas esse certificado pode ser assinado por qualquer pessoa. Pode até ser auto-assinado (assinado pela entidade que criou o certificado). Ao visitar um site protegido com SSL/TLS, o navegador verifica se esse site tem um certificado válido verificando se ele está assinado por um certificado raiz confiável. Ele também verifica se o certificado é para o domínio que você está visitando e exibe informações sobre o proprietário do certificado para você verificar. Se o certificado não for assinado por um certificado raiz confiável, o navegador da Web exibirá um aviso claro. Você geralmente pode optar por ignorar o aviso (dependendo da configuração do navegador da Web), mas você não pode perdê-lo.

Navegação segura

É muito fácil identificar se um site tem um certificado válido e se você está usando uma conexão segura. Tudo o que você precisa fazer é olhar para a barra de endereços (semelhante em todos os principais navegadores).

O bloqueio verde e o protocolo HTTPS (https://) indicam que a conexão com o servidor web é criptografada e segura.

Navegação insegura

Também é fácil identificar um site não protegido. Não há bloqueio verde e não há menção de HTTPS.

No entanto, alguns sites usam HTTP para entregar partes do conteúdo, como imagens. Nesse caso, você verá uma mensagem semelhante a esta:

O conteúdo que é apenas parcialmente protegido é chamado de conteúdo misto. O conteúdo misto derrota o propósito de uma conexão segura. Quando você solicita arquivos de um site onde você está logado, o navegador da Web envia automaticamente seus cookies de autenticação junto com a solicitação.

Portanto, se você carregar um recurso usando HTTP, sua solicitação será enviada por uma conexão não criptografada. Se um invasor está farejando a rede, eles são capazes de ver esta solicitação em plaintext. Isso compromete a segurança de uma sessão, uma vez que um invasor usa cookies para entrar no site e se passar por você. Por essa razão, você deve tratar sites com conteúdo misto da mesma forma que você trata sites não criptografados.

Tipos de Certificados SSL/TLS

Os certificados SSL/TLS estão disponíveis em diferentes sabores. Do ponto de vista técnico, eles podem ser divididos em três grupos, dependendo do escopo dos domínios a que se aplicam.

Domínio único

Esse tipo de certificado se aplica a apenas um nome de host (Nome de domínio totalmente qualificado – FQDN) ou subdomínio. Por exemplo, você pode obter um certificado para www.example.com ou my.example.com. No entanto, mail.example.com não serão incluídas no escopo deste certificado. O certificado só será válido para um nome de host que você especifica durante o registro.

Curinga

Este tipo de certificado se aplica a um domínio inteiro com todos os seus subdomínios. Por exemplo, se você se inscrever *.example.com,o certificado será aplicado a mail.example.com, secret.example.com, admin.example.com, e todos os outrossubdomínios. Você pode hospedar cada subdomínio em um servidor diferente e usar o mesmo certificado SSL/TLS curinga em vários servidores, desde que o domínio seja o mesmo.

Multi-Domínio

Este tipo de certificado se aplica a vários nomes de domínio diferentes. Cada nome de domínio pode ser um único domínio ou um curinga. Normalmente, quando você adquire tal certificado, você pode alterar os nomes de domínio a qualquer momento. Esse tipo de certificado também é frequentemente chamado de certificado SAN (Subject Alternative Name, nome alternativo do sujeito).

Validação do certificado SSL/TLS

Os certificados SSL/TLS também estão disponíveis em diferentes sabores do ponto de vista da validação de identidade. Quanto mais validação de identidade, mais confiável é o certificado, mas quanto mais tempo leva para adquiri-lo.

Validação de domínio

Um certificado de validação de domínio apenas confirma que a pessoa que solicita um certificado é o proprietário do nome de domínio (ou pelo menos tem acesso a ele). Esse tipo de validação geralmente leva apenas alguns minutos até algumas horas.

Validação da Organização

A Autoridade de Certificação (CA) não só valida a propriedade do domínio, mas também a identidade do proprietário. Isso significa que um proprietário pode ser solicitado a fornecer informações pessoais e documentos de identificação que comprovem sua identidade. Essa validação pode levar vários dias.

Validação Estendida

Este é o mais alto nível de validação. Inclui validação de propriedade de domínio e identidade do proprietário, mas também exige que a empresa forneça comprovante de registro legal.

Geração de Certificados

Se você quiser solicitar um certificado de uma Autoridade de Certificado, você precisa gerar uma Solicitação de Assinatura de Certificado (RSE). Primeiro, crie uma chave privada que será usada para descriptografar o certificado. Então, gere a RSE. Quando você gera a RSE, você será solicitado a especificar o nome de domínio, bem como detalhes sobre sua organização, por exemplo, nome, país e e-mail. A seguir, um exemplo de uma RSE.

—–BABA O PEDIDO DE CERTIFICADO—–

MIICtzCCAZ8CAQAwUTELMAkGA1UEBhMCQ1kxCjAIBGNBAgMAWExCzAJBgNVBAcM

Ak1lMQowCAYDVQKDAFhMQowCAYDVQQLDAFhMDeDWDYDVVQDQDAh0ZXN0LmNvbTCCASIWDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKVFdX1qwMNu0i0GHW/lotRKYM0I3yvHQmeS5DtYqmnMGsIZaUO7qv+z8CW4cIIqZhR/hlXEsh+ARM/po37OjzzSDo1U7gyKciSf2s+JsuLmlrHoZPto+/4uWgp9xyQW177/MvWtOVejaUnzrjmPn

AT9KAZ3w+2uwjrhJG5w52psENUT+tTOMDgIVLKSbZcvD5bS/X7RvfsOS3Q/y9wG

Q53rbZqK19y5CtM808wGOQhrNfp3M1EA6+m7RRO1Yw2Rp+wLY0aA9UzjzImaL5Sr

/job1EoJWzKClY20GXB6HKn+wJ/n4sz725bF6l6r4yoBY1f4gYBn3QW+sQXLrDsC

AwEAAaAhMB8GCSqGSIB3DQEJBzESDBBKZmpoZ2tqaGpoZGZZramhnMA0GCSqGSQGIb3

DQEBCwUAA4IBAQCFQ7/R+/ioSj7X4gs+GBbDHEcnJHshwoX9vVBDYvOoQ56iER7f

cEtja18yeXu3PNyeOoDLSYd0FhM16XKLlJ0llIy46Vb8RMdS4JNEx2yob3W/bIAS

z2n+p58zp2/Gp7gG2LtH+RwcvRGRGdKhrsU8D+fHGHpSGvGJg++IhS2HZvTs5pkD

3AwMpDojVYtWuJteDVHGc4PH5TeJot7+6lGetkhq1uRhD4KjJDY5KUvCNQIjeoaL

eFf/xGp6JGNE5taK2liBs+QlgLZc8Sm7fTYCi0YXAsEhMm9HjbXX28Ou6zTroDP3

elT3tN9pd1aG6ujGjkrM6T8JiVWxqYFEnFqd

—–DE PEDIDO DE CERTIFICADO—–

Depois de gerar a RSE, você deve submetê-la ao CA. Quando o certificado estiver pronto, o CA geralmente envia-o para o seu endereço de e-mail como um arquivo *.crt. Você deve instalar este arquivo em seu servidor.

TLS Security 5: Estabelecendo uma conexão TLS

O processo de estabelecer uma conexão SSL/TLS segura envolve várias etapas. Os protocolos de segurança SSL/TLS usam uma combinação de criptografia assimétrica e simétrica. O cliente e o servidor devem negociar os algoritmos usados e trocar informações-chave.

Para explicar esse processo complexo, utilizamos uma conexão TLS 1.2, não o mais recente protocolo TLS 1.3. O processo utilizado no TLS 1.2 foi quase o mesmo para todas as versões anteriores do SSL/TLS. No entanto, foi muito simplificado na versão mais recente do Transport Layer Security.

A parte mais importante do estabelecimento de uma conexão segura é chamada de aperto de mão. Durante o Aperto de mão TLS, o servidor e o cliente trocam informações importantes usadas para determinar propriedades de conexão. Este exemplo é baseado em um aperto de mão do navegador da Web, mas o mesmo se aplica a todos os outros apertos de mão SSL/TLS.

Passo 1: Customer Hello (Customer → Server)

Primeiro, o cliente envia um Cliente Olá para o servidor. O Olá do Cliente inclui as seguintes informações.

Versão do cliente

O cliente envia uma lista de todas as versões do protocolo TLS/SSL que ele suporta com a preferida sendo a primeira da lista. A preferida é geralmente a versão mais recente disponível. Por exemplo, o TLS 1.2 tem um client_version 3,3. Isso ocorre porque o TLS 1.0 é tratado como uma pequena revisão da Secure Sockets Layer (SSL 3.0), então o TLS 1.0 é 3,1, o TLS 1.1 é 3,2, e assim por diante.

Cliente Aleatório

Este é um número aleatório de 32 byte. O cliente aleatório e o servidor aleatório são usados mais tarde para gerar a chave para criptografia.

Na especificação original do TLS 1.2, os primeiros 4 bytes deveriam representar a data e a hora atuais do cliente (em formato de época) e os 28 bytes restantes deveriam ser um número gerado aleatoriamente. No entanto, o IETF mais tarde recomendou contra ele.

ID de sessão

Esta é a id de sessão a ser usada para a conexão. Se o session_id não estiver vazio, o servidor procurará sessões anteriormente armazenadas em cache e retome essa sessão se uma correspondência for encontrada.

compression_methods

Este é o método que será usado para comprimir os pacotes SSL. Usando a compressão, podemos obter menor uso de largura de banda e, portanto, velocidades de transferência mais rápidas. Mais tarde, neste artigo, veremos por que o uso da compressão é arriscado.

Suítes cifrada

Suítes cifras são combinações de algoritmos criptográficos. Normalmente, cada suíte de cifra contém um algoritmo criptográfico para cada uma das seguintes tarefas: troca de chaves, autenticação, criptografia em massa (dados) e autenticação de mensagens. O cliente envia uma lista de todas as suítes cifras que suporta por ordem de preferência. Isso significa que o cliente preferiria idealmente que a conexão fosse estabelecida usando a primeira suíte cifrada enviada.

As suítes cifradas são identificadas por cordas. Uma sequência de suíte de cifra de amostra é: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. Esta sequência contém as seguintes informações:

• TLS é o protocolo que está sendo usado
• ECDHE é o algoritmo de troca-chave (curva elíptica Diffie-Hellman)
• ECDSA é o algoritmo de autenticação (Algoritmo de Assinatura Digital da Curva Elíptica)
• AES_128_GCM é o algoritmo de criptografia de dados (Advanced Encryption Standard 128 bits Galois/Counter Mode)
• SHA256 é o algoritmo código de autenticação de mensagem (MAC) (Algoritmo de Hash Seguro 256 bits)

Métodos de compressão

Esta é uma lista de métodos que serão usados para comprimir dados (antes de criptografá-lo). Se você usar compactação, você pode diminuir o uso da largura de banda e acelerar as transferências. No entanto, a compressão é arriscada e recomendada contra: ver informações sobre ataques de CRIME e VIOLAÇÃO.

Extensões

O cliente pode solicitar funcionalidade adicional para a conexão. Isso pode ser feito através de extensões como grupos suportados para criptografia de curva elíptica, formatos de ponto para criptografia de curva elíptica, algoritmos de assinatura e muito mais. Se o servidor não puder fornecer a funcionalidade adicional, o cliente pode abortar o aperto de mão, se necessário.

Aqui está como um cliente de verdade Hello se parece em uma captura de Wireshark.

Passo 2: Hello do servidor (Servidor → Cliente)

Depois que o servidor recebe o Customer Hello,ele responde com um Servidor Olá. Um Server Hello pode conter opções selecionadas (entre as propostas durante o Client Hello) ou pode seruma mensagem de falha de aperto de mão.

Versão do servidor

O servidor seleciona a versão preferida do protocolo SSL/TLS entre os apresentados pelo cliente.

Servidor Aleatório

Este é um número aleatório de 32 byte. O servidor aleatório e o cliente aleatório são usados mais tarde para gerar a chave de criptografia.

Na especificação original do TLS 1.2, os primeiros 4 bytes deveriam representar a data e a hora atuais do cliente (em formato de época) e os 28 bytes restantes deveriam ser um número gerado aleatoriamente (assim como no caso do Cliente Random). No entanto, o IETF mais tarde recomendou contra ele.

ID de sessão

Se o ID da sessão do cliente não estiver vazio, o servidor procurará sessões anteriormente armazenadas em cache e se uma correspondência for encontrada, esse ID de sessão será usado para retomar a sessão. Se o ID de sessão do cliente estivesse vazio, uma nova sessão poderá ser criada pelo servidor e enviada no ID de sessãodo servidor.

Suítes cifrada

O servidor seleciona o conjunto cifrado entre as Suítes Cifras enviadas no Customer Hello.

Métodos de compressão

O servidor seleciona o método de compressão entre os Métodos de Compressão enviados no Customer Hello.

Passo 3: Certificado do servidor (Servidor → Cliente)

O servidor agora envia um certificado TLS/SSL assinado que comprova sua identidade ao cliente. Ele também contém a chave pública do servidor.

Passo 4: Certificado do Cliente (Servidor de → cliente, opcional)

Em casos raros, o servidor pode exigir que o cliente seja autenticado com um certificado de cliente. Nesse caso, o cliente fornece seu certificado assinado ao servidor.

Passo 5: Troca de chaves de servidor (servidor → cliente)

A mensagem de troca de chaves do servidor é enviada somente se o certificado fornecido pelo servidor não for suficiente para o cliente trocar um segredo pré-mestre. (Isso é verdade para DHE_DSS, DHE_RSA e DH_anon).

Passo 6: Hello Done do servidor (Servidor → Cliente)

O servidor envia isso ao cliente para confirmar que a mensagem Do Servidor Olá está finalizada.

É assim que um Server Hello se parece em uma captura de Wireshark.

Passo 7: Troca de chaves do cliente (servidor → cliente)

A mensagem troca de chaves do cliente é enviada logo após o Servidor Hello Done ser recebido do servidor. Se o servidor solicitar um Certificado de Cliente,a Troca de Chaves do Cliente será enviada depois disso. Durante esta etapa, o cliente cria uma chave pré-mestre.

Segredo pré-mestre

O segredo pré-mestre é criado pelo cliente (o método de criação depende do conjunto cifrado) e depois compartilhado com o servidor.

Antes de enviar o segredo pré-mestre para o servidor, o cliente o criptografa usando a chave pública do servidor extraída do certificado fornecido pelo servidor. Isso significa que apenas o servidor pode descriptografar a mensagem, uma vez que a criptografia assimétrica (par de chaves) é usada para a troca secreta pré-master.

É assim que a troca de chaves se parece em uma captura de Wireshark (usando Diffie-Hellman).

Segredo Mestre

Depois que o servidor recebe a chave secreta pré-mestre, ele usa sua chave privada para descriptografá-la. Agora, o cliente e o servidor computam a chave secreta mestre com base em valores aleatórios trocados anteriormente (Cliente Aleatório e Servidor Aleatório) usando uma funçãopseudorandom (PRF). A PRF é uma função usada para gerar quantidades arbitrárias de dados pseudorandom.

master_secret = PRF(pre_master_secret, “master secret”,ClientHello.random + ServerHello.random) [0.. 47];

A chave secreta mestre, que tem 48 bytes de comprimento, será usada pelo cliente e pelo servidor para criptografar simetricamente os dados para o resto da comunicação.

O cliente e o servidor criam um conjunto de 3 chaves:

• client_write_MAC_key: Verificação de autenticação e integridade
• server_write_MAC_key: Verificação de autenticação e integridade
• client_write_key: Criptografia de mensagens usando chave simétrica
• server_write_key: Criptografia de mensagens usando chave simétrica
• client_write_IV: Vetor de inicialização usado por algumas cifras AHEAD
• server_write_IV: Vetor de inicialização usado por algumas cifras AHEAD

Tanto o Cliente quanto o Server usarão o segredo mestre para gerar as chaves de sessões que serão para criptografar/descriptografar dados.

Passo 8: Especificação cifrada de mudança de cliente (servidor de → cliente)

Neste ponto, o cliente está pronto para mudar para um ambiente seguro e criptografado. O protocolo Change Cipher Spec é usado para alterar a criptografia. Todos os dados enviados pelo cliente a partir de agora serão criptografados usando a chave compartilhada simétrica.

É assim que o Change Cipher Spec se parece em uma captura de Wireshark.

Passo 9: Aperto de mão do cliente acabado (servidor de → cliente)

A última mensagem do processo de aperto de mão do cliente significa que o aperto de mão está terminado. Esta também é a primeira mensagem criptografada da conexão segura.

Passo 10: Especificação cifrada de alteração de servidor (servidor → cliente)

O servidor também está pronto para mudar para um ambiente criptografado. Todos os dados enviados pelo servidor a partir de agora serão criptografados usando a chave compartilhada simétrica.

Passo 11: Aperto de mão do servidor concluído (servidor → cliente)

A última mensagem do processo de aperto de mão do servidor (enviado criptografado) significa que o aperto de mão está terminado.

Recapitulando, o seguinte ilustra um aperto de mão típico.

O aperto de mão TLS em TLS 1.3

No TLS 1.2 e anteriormente, o aperto de mão TLS precisava de duas viagens de ida e volta para ser concluído. A primeira ida e volta foi a troca de saudações e a segunda foi a troca de chaves e a mudança da especificação cifrada. No TLS 1.3, esse processo é simplificado e apenas uma ida e volta é necessária. O TLS 1.3 também não suporta mais a compressão TLS.

No TLS 1.3, quando o cliente envia seu olá, ele imediatamente adivinha o protocolo de contrato chave que o servidor provavelmente selecionará. Ao mesmo tempo, compartilha sua chave usando o protocolo adivinhado. A mensagem de olá do servidor também contém a chave compartilhada, o certificado e a mensagem finalizada do servidor. Não há necessidade de mudança de cifra, pois após a troca de olás ambas as partes já têm tudo o que precisam para criptografar a comunicação.

TLS Security 6: Exemplos de vulnerabilidades e ataques do TLS

Os protocolos criptográficos Secure Sockets Layer (SSL) e o Transport Layer Security (TLS) tiveram sua parcela de falhas como todas as outras tecnologias. A seguir, as principais vulnerabilidades nos protocolos TLS/SSL. Todos eles afetam versões mais antigas do protocolo (TLSv1.2 e mais antigos). No momento da publicação, apenas uma grande vulnerabilidade foi encontrada que afeta o TLS 1.3. No entanto, como muitos outros ataques listados aqui, essa vulnerabilidade também é baseada em um ataque de downgrade forçado.

Nota — Devido à complexidade de ataques e vulnerabilidades que exploram, as descrições são simplificadas e baseadas em exemplos da Web (cliente web e servidor web).

Poodle

O ataque do Endding Oracle On Downgraded Legacy Encryption (POODLE) foi publicado em outubro de 2014 e aproveita dois fatores. O primeiro fator é o fato de que alguns servidores/clientes ainda suportam o SSL 3.0 para interoperabilidade e compatibilidade com sistemas legados. O segundo fator é uma vulnerabilidade que existe no SSL 3.0, que está relacionado ao preenchimento do bloco. A vulnerabilidade POODLE está registrada no banco de dados NIST NVD como CVE-2014-3566.

O cliente inicia o aperto de mão e envia uma lista de versões SSL/TLS suportadas. Um invasor intercepta o tráfego, realizando um ataque man-in-the-middle (MITM) e se passa pelo servidor até que o cliente concorde em rebaixar a conexão para o SSL 3.0.

A vulnerabilidade SSL 3.0 está no modo Cipher Block Chaining (CBC). As cifras de bloco requerem blocos de comprimento fixo. Se os dados no último bloco não forem múltiplos do tamanho do bloco, o espaço extra será preenchido por preenchimento. O servidor ignora o conteúdo do preenchimento. Ele só verifica se o comprimento do preenchimento está correto e verifica o Código de Autenticação de Mensagem (MAC) do texto simples. Isso significa que o servidor não pode verificar se alguém modificou o conteúdo do preenchimento.

Um invasor pode decifrar um bloco criptografado modificando bytes de preenchimento e observando a resposta do servidor. É preciso um máximo de 256 solicitações SSL 3.0 para descriptografar um único byte. Isso significa que uma vez a cada 256 solicitações, o servidor aceitará o valor modificado. O invasor não precisa saber o método de criptografia ou a chave. Usando ferramentas automatizadas, um invasor pode recuperar o caractere de texto simples por caractere. Isso pode facilmente ser uma senha, um cookie, uma sessão ou outros dados confidenciais.

Prevenção

• Desabilitar completamente o SSL 3.0 no servidor (altamente recomendado a menos que você deva suportar o Internet Explorer 6.0).
• Atualize o navegador (cliente) para a versão mais recente. Se você deve usar uma versão mais antiga, desabilitar SSLv2 e SSLv3. A maioria dos navegadores/servidores atuais usa TLS_FALLBACK_SCSV. Se um cliente solicitar uma versão de protocolo TLS menor do que a mais alta suportada pelo servidor (e cliente), o servidor irá tratá-lo como um downgrade intencional e soltar a conexão.
• Algumas implementações TLS 1.0/1.1 também são vulneráveis ao POODLE porque aceitam uma estrutura de preenchimento incorreta após a descriptografia.

BESTA

O ataque de Exploração do Navegador Contra SSL/TLS (BEAST) foi divulgado em setembro de 2011. Ele se aplica ao SSL 3.0 e ao TLS 1.0 para que ele afete navegadores que suportam protocolos TLS 1.0 ou anteriores. Um invasor pode descriptografar dados trocados entre duas partes aproveitando-se de uma vulnerabilidade na implementação do modo Cipher Block Chaining (CBC) no TLS 1.0. A vulnerabilidade BEAST está registrada no banco de dados NIST NVD como CVE-2011-3389.

Este é um ataque do lado do cliente que usa a técnica homem no meio. O invasor usa o MITM para injetar pacotes no fluxo TLS. Isso permite que eles adivinhem o Vetor de Inicialização (IV) usado com a mensagem injetada e, em seguida, basta comparar os resultados com os do bloco que eles querem descriptografar.

Para que o ataque beast tenha sucesso, um invasor deve ter algum controle do navegador da vítima. Portanto, o atacante pode escolher vetores de ataque mais fáceis em vez deste.

Prevenção

• Use TLS 1.1 ou TLS 1.2

Nota — Originalmente, um dos métodos recomendados para mitigar ataques BEAST era usar a cifra RC4. No entanto, o protocolo de criptografia RC4 foi mais tarde considerado inseguro. O PCI DSS (Payment Card Industry Data Security Standard) proíbe o uso dessa cifra e a Microsoft também recomenda fortemente contra usá-la no Windows.

CRIME (CVE-2012-4929)

A vulnerabilidade de info-leak da relação de compressão Made Easy (CRIME) afeta a compactação TLS. O método de compressão está incluído na mensagem Customer Hello e é opcional. Você pode estabelecer uma conexão sem compressão. A compressão foi introduzida no SSL/TLS para reduzir a largura de banda.  DEFLATE é o algoritmo de compressão mais comum usado. A vulnerabilidade do CRIME está registrada no banco de dados NIST NVD como CVE-2012-4929.

Esta é uma captura de Wireshark de uma mensagem Server Hello (resposta ao Cliente Olá). O servidor seleciona o método de compactação NULL, o que significa que nenhuma compactação será usada.

Uma das principais técnicas utilizadas pelos algoritmos de compressão é substituir sequências repetidas de byte por um ponteiro para a primeira instância dessa sequência. Quanto maiores as sequências repetidas, maior a razão de compressão.

Vamos supor que o agressor quer pegar o biscoito da vítima. Eles sabem que o site alvo (examplebank.com) cria um cookie para a sessão chamada adm. O atacante sabe que o método de compactação DEFLATE substitui bytes repetidos. Portanto, o agressor injeta Cookie:adm=0 no cookie da vítima. O servidor anexará apenas 0 à resposta compactada porque Cookie:adm= já está enviado no cookie da vítima, por isso é repetido.

Tudo o que o invasor deve fazer é injetar diferentes caracteres e, em seguida, monitorar o tamanho da resposta. Se a resposta for menor que a inicial, o caractere injetado está contido no valor do cookie e por isso foi comprimido. Se o caractere não estiver no valor do cookie, a resposta será maior.

Usando este método, um invasor pode reconstruir o valor do cookie usando o feedback que eles obtêm do servidor.

Prevenção

• Atualize seu navegador para a versão mais recente

Violação

A vulnerabilidade de Reconhecimento e Exfiltração do Navegador via Compactação Adaptativa do Hypertext (BREACH) é muito semelhante ao CRIME, mas o BREACH visa a compressão HTTP, não a compactação TLS. Este ataque é possível mesmo se a compressão do TLS for desligada. Um invasor força o navegador da vítima a se conectar a um site de terceiros habilitado para TLS e monitora o tráfego entre a vítima e o servidor usando um ataque de homem no meio. A vulnerabilidade BREACH está registrada no banco de dados NIST NVD como CVE-2013-3587.

Um aplicativo web vulnerável deve satisfazer as seguintes condições:

• Seja servido a partir de um servidor que usa compactação de nível HTTP
• Reflita a entrada do usuário em corpos de resposta HTTP
• Reflita um segredo (como um token CSRF) em corpos de resposta HTTP (portanto, os valores em cabeçalhos HTTP, como cookies, estão a salvo deste ataque).

Prevenção

• Desativar a compressão HTTP
• Separar segredos da entrada do usuário
• Randomize segredos por solicitação
• Segredos da máscara (efetivamente randomize por XORing com um segredo aleatório por solicitação)
• Proteger páginas contra CSRF
• Ocultar o comprimento (adicionando números aleatórios de bytes às respostas)
• Limitar a taxa de solicitações

Coração

Heartbleed foi uma vulnerabilidade crítica que foi encontrada na extensão de batimentos cardíacos da popular biblioteca OpenSSL. Esta extensão é usada para manter uma conexão viva enquanto ambas as partes ainda estiverem lá. A vulnerabilidade Heartbleed está registrada no banco de dados NIST NVD como CVE-2014-0160.

O cliente envia uma mensagem de batimentos cardíacos para o servidor com uma carga útil que contém dados e o tamanho dos dados (e preenchimento). O servidor deve responder com a mesma solicitação de batimentos cardíacos, contendo os dados e o tamanho dos dados que o cliente enviou.

A vulnerabilidade heartbleed baseava-se no fato de que, se o cliente enviasse um comprimento de dados falso, o servidor responderia com os dados recebidos pelo cliente e dados aleatórios de sua memória para atender aos requisitos de comprimento especificados pelo remetente.

O vazamento de dados não criptografados da memória do servidor pode ser desastroso. Houve explorações de prova de conceito dessa vulnerabilidade em que o invasor obteria a chave privada do servidor. Isso significa que um invasor seria capaz de descriptografar todo o tráfego para o servidor. A memória do servidor pode conter qualquer coisa: credenciais, documentos confidenciais, números de cartão de crédito, e-mails, etc.

Prevenção

• Atualize para a versão mais recente do OpenSSL. Se isso não for possível, recompile a versão já instalada com -DOPENSSL_NO_HEARTBEATS

Conclusão

Os protocolos SSL/TLS são usados para proteger a transmissão de dados, mas servidores mal configurados podem expor dados em vez de ligá-los. Uma maneira fácil de testar se seu site ou aplicativo web usa uma configuração SSL/TLS vulnerável é executar uma varredura automatizada usando o scannerde vulnerabilidade Acunetix on-line,que inclui um scanner de segurança de rede. Ao mesmo tempo, você também pode testar para vulnerabilidades da Web.  Solicite uma demonstração para ver como você pode identificar e relatar configurações inseguras.

Na maioria dos casos, a melhor maneira de se proteger contra ataques relacionados ao SSL/TLS é desativar versões de protocolo mais antigas. Este é até um requisito padrão para algumas indústrias. Por exemplo, 30 de junho de 2018, foi o prazo final para desativar o suporte para SSL e versões iniciais do TLS (até e incluindo o TLS 1.0) de acordo com o PCI Data Security Standard. A Força-Tarefa de Engenharia da Internet (IETF) divulgou avisos sobre a segurança da SSL: RFC 6176 e RFC 7568. A depreciação do TLS 1.0 e 1.1 pelo IETF é esperada em breve.

mTLS

O “m” significa “mútuo”.

O cliente e o servidor verificam as identidades um do outro antes de prosseguir para a troca HTTP.

O cliente deve ter e enviar um certificado assinado por uma CA que o servidor reconheça.

Em ambientes corporativos, geralmente é uma CA interna administrada pela empresa.

Uma visão geral das vulnerabilidades TLS

As explorações em estado selvagem podem ter como alvo falhas no protocolo TLS, incluindo primitivas criptográficas fracas ou erros de implementação específicos, vulnerabilidades de protocolo cruzado ou qualquer combinação dos itens acima.

Falhas conceituais em TLS e as explorações resultantes

As vulnerabilidades de TLS são um centavo a dúzia – pelo menos enquanto as versões obsoletas do protocolo ainda estão em implantação ativa.

Alguns vetores de ataque principais surgem de falhas conceituais no próprio padrão TLS. Recursos sujeitos a vulnerabilidades incluem downgrades de protocolo , renegociação de conexão e retomada de sessão . Especificações incompletas ou vagas, especialmente quando se trata de interações de protocolo cruzado (ou seja, entre TLS e protocolos de aplicativo como HTTP) geram algumas vulnerabilidades graves, particularmente no caso de  vetores de ataque de protocolo cruzado contra TLS , dos quais existem alguns.

TLS 1.3 (veja o rascunho final ) é a primeira versão do protocolo que não permite renegociação, bem como downgrades e atualizações de protocolo que deram origem a POODLE e LOGJAM.

3SHAKE

Um ataque 3SHAKE requer que um cliente honesto se conecte a um servidor malicioso e apresente uma credencial de cliente. Depois de obter a credencial, o servidor mal-intencionado pode representar o cliente em qualquer outro servidor que aceite a mesma credencial. Para esse fim, o servidor malicioso executa um ataque man-in-the-middle (MiTM) em três apertos de mão sucessivos entre o cliente honesto e outro servidor e consegue personificar o cliente no terceiro aperto de mão .

O ataque explora a falta de vinculação de conexão cruzada de retomada da sessão TLS em novas conexões. Ele funciona em servidores que executam autenticação baseada em certificado do cliente e oferecem suporte tanto para retomada quanto para renegociação.

Variações do ataque podem comprometer outros mecanismos de autenticação baseados em TLS que não dependem de renegociação, como PEAP, SASL (SCRAM, GS2) e ID de canal.

Para atenuar esses tipos de ataques, o TLS 1.3 proíbe a renegociação.

TLS Renego MITM

Em um ataque TLS Renego MITM, um adversário faz uma conexão TLS que foi tentada pela primeira vez por um cliente legítimo. O invasor pode estabelecer a conexão antes do cliente ou efetuar o ataque usando a renegociação de sessão. Infelizmente, as conexões de autenticação de cliente baseadas em certificado mútuo não são imunes.

A falha conceitual mais flagrantemente absurda ficou evidente no SSL v2. O invasor MITM poderia simplesmente criar uma mensagem de encerramento falsa, conectar-se à sessão SSL e enganar as partes fazendo-as pensar que sua comunicação ainda estava “segura”.

Os fornecedores corrigiram a vulnerabilidade de acordo com a RFC 5746.

POODLE

POODLE ( Padding Oracle On Downgraded Legacy Encryption,  CVE-2014-8730) é um ataque man-in-the-middle que depende de um downgrade de protocolo de TLS 1.0, 1.1 ou 1.2 para SSLv3.0 para tentar um ataque de força bruta contra Preenchimento CBC.

A CORREÇÃO: o TLS 1.3 oferece proteção contra POODLE ao não permitir um downgrade de protocolo.

LOGJAM

O ataque LOGJAM depende de um downgrade de conexões TLS vulneráveis ​​para criptografia de nível de exportação de 512 bits que usa grupos DH fracos.

A CORREÇÃO: o TLS 1.3 oferece proteção contra LOGJAM ao não permitir cifras de exportação.

FREAK

O ataque FREAK ( Factoring RSA Export Keys ) envolvia enganar os servidores para que negociassem uma conexão com uma versão anterior do TLS (como SSLv2) usando chaves de criptografia de 512 bits criptograficamente fracas.

A CORREÇÃO: TLS 1.3 oferece proteção contra FREAK ao não permitir um downgrade de protocolo.

Vulnerabilidades TLS resultantes de primitivas criptográficas fracas

Muitas vulnerabilidades TLS conhecidas resultam de primitivas criptográficas fracas, que o TLS 1.3, felizmente, eliminou.

No TLS até a versão 1.2, algumas cifras de bloco podem operar no modo de encadeamento de bloco de cifra  (CBC para abreviar). O CBC foi pensado para neutralizar a manipulação, pois a integridade dos dados de cada bloco depende da criptografia adequada do bloco anterior. O CBC IV para cada registro, exceto o primeiro, é o último bloco de texto cifrado dos registros anteriores. Implementações defeituosas de CBC em TLS 1.0 permitiram o surgimento do ataque BEAST. A prevalência dessas implementações defeituosas levou à remoção do CBC do TLS 1.3.

Ao usar uma cifra de bloco, o comprimento de todas as mensagens de texto simples deve ser um múltiplo do tamanho do bloco da cifra; uma discrepância de comprimento requer preenchimento que estende o comprimento da mensagem para que se ajuste ao último bloco). Dependendo do algoritmo, a seção de preenchimento normalmente deriva do texto simples de alguma forma. Durante a descriptografia, o preenchimento é verificado; preenchimento inválido produz um erro. Um invasor pode manipular o preenchimento para acionar erros e diferenças de tempo com base nessas modificações para tentar adivinhar o conteúdo da mensagem. Esse chamado ataque de oráculo de preenchimento  no TLS até a versão 1.2 pode comprometer o texto simples.

No TLS 1.3, o CBC não é permitido e o uso obrigatório de conjuntos de criptografia AEAD elimina vulnerabilidades associadas a ataques de oráculo de preenchimento.

Sweet32, um ataque a cifras de bloco de 64 bits

Sweet32 é um ataque de colisão de bloco contra CBC. Ele quebra todas as cifras de bloco de 64 bits no modo CBC com uma combinação de um ataque de aniversário e um ataque MITM ou uma injeção de JavaScript em um site para facilitar um grande número de solicitações HTTP.

Esse ataque pode comprometer dados críticos que estão sendo enviados repetidamente, como um token de autenticação contido em cada solicitação. Isso é particularmente verdadeiro com conexões HTTP persistentes (em HTTP/1.1, Keep-Alive), pois essas permitem a troca de um grande número de solicitações HTTP sem recodificação.

A mitigação envolve a desativação de pacotes de cifras baseados em DES triplo (3DES).

ROBÔ ou retorno do ataque Oracle de Bleichenbacher

ROBOT ( Return of Bleichenbacher’s Oracle Attack ) alavanca modos de preenchimento inseguros (como RSA PKCS # 1 v1.5), que abre a possibilidade de falsificação de assinatura . Este é mais um ressurgimento do CRYPTO’98 de Bleichenbacher.

Como se já não tivesse havido o suficiente ( ver página 4 ):

• Bleichenbacher (CRYPTO 1998)
• Klima et al. (CHES 2003)
• Jager et al. (ESORICS 2012)
• Degabriele et al. (CT-RSA 2012)
• Bardou et al. (CRYPTO 2012)
• Zhang et al. (ACM CCS 2014)
• Meyer et al. (USENIX Security 2014)
• Aviram et al. (DROWN, USENIX Security 2016)

A CORREÇÃO: TLS 1.3 não permite o mecanismo de transporte de chave inseguro conhecido como  RSA-PKCS # 1 v1.5.

LUCKY13

LUCKY13  é um ataque de sincronização criptográfica contra implementações de TLS até e incluindo 1,2 ao usar o modo CBC de operação de uma cifra em massa. É uma variação do ataque de oráculo de enchimento de Serge Vaudenay que antes se acreditava corrigido. Uma variante do ataque LUCKY13 pode funcionar, pelo menos em teoria,  contra a implementação de código aberto do TLS conhecido como  s2n  que foi desenvolvido pelo Amazon Security Labs.

O ataque de Vaudenay depende da capacidade do atacante de distinguir erros bad_record_mac e decryption_failed.

A CORREÇÃO: Habilite o TLS 1.3, desabilite os conjuntos de criptografia CBC no TLS 1.2, desabilite as versões anteriores do TLS. Além de proibir as cifras CBC, o TLS 1.3 usa o alerta bad_record_mac para todas as falhas de desproteção. Isso deve proteger a conexão de ataques de canal lateral, como Vaudenay e LUCKY13.

Em uma tentativa de corrigir a vulnerabilidade LUCKY13, os desenvolvedores do OpenSSL/LibreSSL inadvertidamente introduziram um novo bug :  LUCKYminus20.

Vulnerabilidades de implementação de TLS

As vulnerabilidades TLS resultantes de implementações com falha são abundantes. Alguns deles dão origem a ataques de protocolo de camada cruzada e/ou ataques de canal lateral.

Combine várias dessas vulnerabilidades e você terá um desastre em formação.

BEAST (exploração do navegador contra SSL/TLS)

BEAST é principalmente uma vulnerabilidade do lado do cliente no TLS 1.0. Este ataque de protocolo de camada cruzada aproveita as fraquezas no encadeamento de blocos de criptografia (CBC)  para permitir ataques man-in-the-middle contra TLS. Ele permite que o invasor, dado um número suficiente de suposições, obtenha credenciais de autenticação, tokens de sessão baseados em URL ou cookies de sessão HTTP.

Preenchimento CBC com defeito em TLS 1.0

Antes da criptografia com uma cifra de bloco, o servidor usará um vetor de encadeamento inicial (ICV ou IV, abreviação de vetor de inicialização ) para mascarar os dados de texto simples para que a criptografia não seja determinística. O cliente também fará isso com os dados que envia e um Vetor de inicialização próprio.

Com o CBC, um atacante man-in-the-middle (MITM) ativo pode prever os blocos IV e, em seguida, fazer suposições sobre a aparência do texto simples e validar essas suposições. O invasor não pode descriptografar o tráfego, mas, dado um número suficiente de suposições corretas, inevitavelmente encontrará alguma forma de credenciais de autenticação.

BEAST ( documentado em 2011) é uma exploração do lado do cliente. A técnica de mitigação do lado do servidor original envolvia a aplicação do uso de suítes RC4  (RC4 significa Rivest Cipher 4), mas essas, infelizmente, ficaram aquém das expectativas (consulte Bar Mitzvah, RC4 NOMORE). TLS 1.1 e 1.2 podem ou não ser imunes ao BEAST. (Vulnerabilidades de TLS supostamente fechadas antigas têm ressurgido em novos cenários com mais ou menos regularidade.)

A CORREÇÃO: as  conexões TLS 1.3 são imunes a essa vulnerabilidade TLS porque o uso de CBC não é permitido.

CRIME e TIME

CRIME (vazamento de informações de taxa de compressão facilitado) é um  ataque de protocolo de camada cruzada que inclui um ataque de canal lateral de compressão contra HTTPS. Ele aproveita as informações vazadas pela compactação TLS nas mensagens enviadas do cliente para o servidor. O CRIME pode recuperar partes específicas do texto simples dado um acesso MiTM.

Em março de 2013 no Black Hat (UE) , Tal Be’ery apresentou uma extensão do CRIME chamada TIME. Ele estreou dois novos aprimoramentos: ele usou CRIME para mensagens de servidor para cliente e não exigia uma situação MiTM explorando tamanhos de janela TCP. A primeira dessas duas modificações deu origem ao BREACH (ver mais adiante).

A CORREÇÃO: O CRIME é ineficaz contra o TLS 1.3 porque o TLS 1.3 desativa a compactação no nível do TLS.

Para verificar se um servidor é vulnerável a CRIME na porta 443:

openssl s_client -conect nomededomínio.com:443

Na saída desse comando, procure a compactação TLS; se habilitado, o servidor fica vulnerável a CRIME.

VIOLAÇÃO

O BREACH , também conhecido como A BREACH além do CRIME ( Reconhecimento e Exfiltração do Navegador via Adaptive Compression of Hypertext , CVE-2013-3587 ), foi “inspirado” pelo exploit CRIME, mas representa uma vulnerabilidade separada.

Um ataque BREACH depende da compactação em nível de HTTP para ler um segredo de sessão do usuário (como um token CSRF) do corpo de uma resposta HTTP que o reflete; ele funciona independentemente da versão TLS usada e é eficaz em qualquer pacote de criptografia. Uma maneira de atenuar isso depende da desativação total da compactação em nível de HTTP.

A anatomia do ataque BREACH

Para verificar se um servidor está vulnerável, execute:

openssl s_client – conectar nome de domínio . com : 443

Na saída, procure sinais de compactação HTTP habilitada, como deflate (“ Aceitar – Codificação : compactar , gzip” ).

Um ataque combinando elementos de BREACH e CRIME ficou conhecido como HEIST.

De TIME a HEIST

Um ataque apelidado de TIME, apresentado pela primeira vez no Black Hat EU em 2013, não chamou a atenção da mídia. Ele logo reapareceu como HEIST na conferência Black Hat USA em agosto de 2016.

HEIST ( informações criptografadas por HTTP podem ser roubadas por meio de TCP-Windows ) refere-se a um conjunto de novas técnicas que trazem ataques em nível de rede contra TLS para o navegador no espírito de CRIME e BREACH (mas desta vez, usando a API Fetch). As técnicas de ataque por trás do HEIST abrangem várias camadas: navegador, HTTP, TLS e TCP.

HEIST levou à descoberta de um ataque de canal lateral contra TLS que vaza o comprimento exato da mensagem de texto simples de qualquer resposta de origem cruzada. O exploit não necessita farejar o tráfego de rede real (ao contrário, por exemplo, CRIME). Em vez disso, ele combina ataques contra TLS usando o recurso de compactação HTTP com um ataque de canal lateral de temporização usando JavaScript. A vulnerabilidade afeta as conexões HTTP 1.1 e HTTP/2, permitindo técnicas ainda mais prejudiciais no último cenário (consulte a página 11 do documento de pesquisa original ).

Uma visão geral de um cenário de ataque HEIST: revelando o estado pessoal do usuário ( fonte )

Uma das melhores maneiras de atenuar o HEIST envolve a desativação de cookies de terceiros no navegador da web. Embora a maioria dos navegadores ofereça suporte a esse recurso, ele deve ser ativado no lado do cliente pelo usuário final.

Desativar a compactação (no lado do servidor) não fornece proteção completa, pois não aborda outros vetores de ataque baseados em comprimento.

BICHO-PREGUIÇA

SLOTH ( Perdas de Segurança de Hashes de Transcrição Obsoleta e Truncada ) é o nome dado a um grupo de vulnerabilidades TLS que facilitam técnicas de ataque de colisão contra transcrições baseadas em hash fracas. O nome se refere à preguiça dos administradores que deixam essas vulnerabilidades TLS no local.

NÃO use funções de hash vulneráveis ​​(isso significa, atualmente, sem  hashes MD5 e SHA-1 ). Felizmente, o TLS 1.3 também acabou com isso.

AFOGAR

DROWN ( descriptografar RSA com criptografia obsoleta e enfraquecida ) é um ataque de protocolo cruzado eficaz contra um servidor que usa a mesma chave privada que o mesmo ou até mesmo qualquer outro servidor com SSLv2 ativado. Por exemplo, um invasor pode usar SSLv2 em um servidor de e-mail para fazer com que ele vaze sua chave privada, o que quebrará a criptografia mais forte em um servidor da web que também usa a mesma chave.

SMACK

SMACK  (State Machine AttaCKs)como FREAK  (Factoring RSA Export Keys) significa exploits de representação de servidor contra navegadores convencionais que visam implementações defeituosas de pacotes de criptografia de exportação fracos.

ROCA

Uma falha em uma biblioteca TLS da empresa alemã de semicondutores Infineon Technologies torna uma variedade de dispositivos vulneráveis ​​ao ataque ROCA quando eles trocam chaves RSA.

ROCA (“ Return of the Coppersmith Attack “, CVE-2017-15361) é facilitado por uma falha criptográfica que permite que um invasor recupere a chave privada da chave pública em pares de chaves que foram gerados por dispositivos com a vulnerabilidade. Apenas o conhecimento de uma chave pública é necessário; o invasor não precisa de acesso físico ao dispositivo vulnerável.

Além disso, a vulnerabilidade ROCA não depende de um gerador de números aleatórios fraco ou defeituoso. Todas as chaves RSA geradas por um chip defeituoso são vulneráveis ​​ao ataque.

O impacto do ROCA, uma das muitas vulnerabilidades de TLS devido a implementações com falha (CVE-2017-15361)

A fonte da vulnerabilidade ROCA é um bug conceitual no RSALib , uma biblioteca de software fornecida pela Infineon. Suas implementações incluem smart cards criptográficos, Trusted Platform Modules (TPM), vários chipsets e outro hardware “seguro”.

Vulnerabilidades TLS resultantes de explorações baseadas em certificados

Vários vetores de ataque contra TLS estão relacionados a vulnerabilidades de certificado.

Em 2018, os pesquisadores da Fidelis Security descobriram essa falha na troca de certificados durante o aperto de mão TLS.

Transferência secreta de executáveis ​​via extensões X.509

Durante o handshake TLS, o servidor envia seu certificado ao cliente (e, opcionalmente, vice-versa). Colocando dados binários arbitrários no certificado. Os dados transferidos por meio de extensões X.509 podem incluir um binário malicioso; ao atravessar a Internet sobre o tráfego de negociação TLS, provavelmente irá ignorar os métodos de detecção que não inspecionam os valores dos certificados. Isso abre a possibilidade de usar conexões TLS para comunicação de comando e controle (CnC). Jason Reaves, engenheiro principal de pesquisa de ameaças da Fidelis Security, escreve em sua análise :

Os certificados X.509 têm muitos campos onde as strings podem ser armazenadas … Os campos incluem versão, número de série, nome do emissor, período de validade e assim por diante. O abuso de certificado … aproveita esse fato para ocultar a transferência de dados dentro de um desses campos. Uma vez que a troca de certificados acontece antes de a sessão TLS ser estabelecida, parece nunca haver transferência de dados, quando na realidade os dados foram transferidos dentro da própria troca de certificados.

A prova de conceito usa certificados autoassinados. A menos que você queira verificar os executáveis ​​que podem estar escondidos nesses certificados, rejeite os certificados autoassinados.

“Os pesquisadores continuam a encontrar novas maneiras de abusar de protocolos e implementações de RFC para obter métodos de transferência de dados difíceis de detectar”, disse Reaves. Na verdade eles fazem.

A lista acima não é, de forma alguma, completa.

Versões vulneráveis ​​do protocolo TLS e primitivas criptográficas fracas são uma receita para uma onda interminável de incidentes de segurança cibernética. As vulnerabilidades TLS podem muito bem mantê-lo na borda de sua cadeira, a menos que você tome as coisas em suas próprias mãos para fechar vetores de ataque conhecidos.

Como mitigar vulnerabilidades TLS conhecidas

Comecemos pelo princípio: como saber se o seu servidor foi afetado? Por que, execute alguns diagnósticos, é claro.

Utilitários de diagnóstico TLS úteis

A empresa suíça High-Tech Bridge SA oferece um excelente teste de configuração TLS online em:

https://www.htbridge.com/ssl/

O Qualys SSL Labs pode testar seus servidores web e agentes de usuário :

https://www.ssllabs.com/ssltest/

Existem também alguns scripts interessantes de domínio público, por exemplo, este no Superuser.

Correções de vulnerabilidade TLS

Aqui está o que você pode fazer para mitigar quaisquer vulnerabilidades de TLS que seus testes descobrirem (o seguinte é baseado nas recomendações de  CloudFlare e Qualys SSL Labs ):

1. desative todas as versões de SSL, bem como TLS 1.0 e 1.1; ativar TLS 1.2 e 1.3
2. desative a compactação de cabeçalho em TLS (SPDY 3.1 é obsoleto); TLS 1.3 não tem compressão de cabeçalho
3. desligue a cifra de stream RC4 (Rivest Cipher 4 também conhecido como ARC4 ou ARCFOUR, abreviação de Suposto RC4)
4. não permitir renegociação com clientes
5. livrar-se de cifras de exportação (isso por si só irá proteger seu servidor, por exemplo, de FREAK )
6. não permitir modos de preenchimento inseguros em TLS 1.2 (como RSA PKCS # 1 v1.5)
7. desabilite os modos CBC MAC-then-Encrypt vulneráveis ​​para proteger de Vaudenay, Lucky13, POODLE, LuckyMinus20 e outros vetores de ataque
8. ativar o suporte para TLS_FALLBACK_SCSV, uma extensão de protocolo que impede que invasores MITM forcem um downgrade de protocolo; as versões atuais do OpenSSL oferecem esse recurso fora da caixa, mas ele só funciona se o cliente e o servidor suportarem

Selecionar conjuntos de criptografia não é tão fácil quanto parece. Para obter mais informações sobre como fechar vulnerabilidades de TLS, consulte “ Pacotes de criptografia TLS 1.3 (com AEAD) e TLS 1.2 desmistificados: como escolher suas criptografias com sabedoria “.

Sigilo direto perfeito em TLS 1.3: fato ou ficção?

TLS 1.3 oferece sigilo de encaminhamento perfeito (com exceção de conexões que usam retomada de sessão 0-RTT). Este recurso protege os dados trocados em uma sessão de serem descriptografados com uma chave comprometida em uma sessão posterior.

O Forward Secrecy refere-se a uma troca de chaves na qual a chave compartilhada que criptografa o fluxo de dados entre duas partes não está relacionada ao seu par de chaves pública/privada.

O Perfect Forward Secrecy requer que, além de oferecer Forward Secrecy, novas chaves compartilhadas sejam geradas para cada conversa e sejam independentes umas das outras.

O TLS 1.3 oferece sigilo de encaminhamento perfeito, exceto no caso de retomada da sessão 0-RTT.

Além disso, o sigilo direto perfeito se baseia nas premissas de que:

• o desafio matemático que deve ser resolvido para gerar chaves de sessão é muito complicado de executar em tempo real (portanto, você deseja escolher seu pacote de criptografia com sabedoria )
• caso as chaves de sessão sejam comprometidas, os invasores são incapazes de decodificar retroativamente comunicações pré-gravadas porque elas dependem de outras chaves de sessão não relacionadas que já foram descartadas

Ferramentas para identificação

Análise de Certificados

O-Saft (https://owasp.org/www-project-o-saft/)

Ferramenta forense avançada OWASP SSL/auditoria OWASP SSL para testadores

O-Saft é uma ferramenta fácil de usar para mostrar informações sobre o certificado SSL e testar a conexão SSL de acordo com determinada lista de cifras e várias configurações SSL.

Ele é projetado para ser usado por testadores de penetração, auditores de segurança ou administradores de servidor. A ideia é mostrar as informações importantes ou as verificações especiais com uma simples chamada da ferramenta. No entanto, ele oferece uma ampla gama de opções para que possa ser usado para verificações abrangentes e especiais por pessoas experientes.

O-Saft é uma ferramenta de linha de comando, portanto, pode ser usada offline e em ambientes fechados. Também existe uma GUI baseada em Tcl/Tk. No entanto, pode simplesmente ser transformado em uma ferramenta CGI on-line (leia a documentação primeiro).

Introdução

Instalação rápida:

• Baixe e descompacte o-saft.tgz (versão estável)
• para executar o-saft: Certifique-se de que os seguintes módulos perl (e suas dependências) estão instalados
  • IO :: Socket :: INET, IO :: Socket :: SSL, Net :: SSLeay
  • Net :: SSLinfo, Net :: SSLhello (que fazem parte do tarball)
• leia e (remova) o-saft-README

Mostre ajuda

• o-saft –help=commands
• o-saft –help

Começar

• o-saft +info your.tld
• o-saft +check your.tld
• o-saft +quick your.tld
• o-saft +cipherall your.tld
• o-saft +cipherall –starttls=pop3 pop3.your.tld:110
• o-saft +info mail.tld:25 –starttls
• para executar o checkAllCiphers opcional (pequeno programa para verificar apenas cifras, como o comando ‘+ cipherall’):
  Geralmente não é necessário que nenhum módulo perl seja instalado adicionalmente

   

  • Soquete (deve fazer parte da instalação do perl)
  • Net :: SSLhello (que faz parte do tarball)
  • NET :: DNS (apenas necessário, se a opção ‘–mx’ for usada)

Começar

• checkAllCiphers your.tld
• checkAllCiphers –starttls=pop3 pop3.your.tld:110
• checkAllCiphers –mx your.tld:25 –starttls=smtp

GUI simples

• o-saft.tcl
• o-saft.tcl your.tld

Versão 2019

• apt install o-saft # installs version 19.01.19
• apt install libidn11-dev libidn2-0-dev libzip-dev libsctp-dev libkrb5-dev
• cd /usr/share/o-saft
• # get updated script
• curl -O contrib/install_openssl.sh https://raw.githubusercontent.com/OWASP/O-Saft/master/contrib/install_openssl.sh
• sh contrib/install_openssl.sh –m
• # enjoy commands as described before …

Descrição

A ideia principal é ter uma ferramenta que funcione em plataformas comuns e possa ser simplesmente automatizada.

Resumindo:

• mostrar detalhes de conexão SSL
• mostrar detalhes do certificado
• verifique as cifras suportadas
• verifique as cifras fornecidas em seu próprio libssl.so e libcrypt.so
• verifique se há cifras sem qualquer dependência de uma biblioteca (+ cipherall)
• verifica a prioridade do servidor para cifras (+ cipherall)
• verifique se há suporte HTTP (S) especial (como SNI, HSTS, pinning de certificado, SSTP)
• verifique se há vulnerabilidades (BEAST, CRIME, DROWN, FREAK, Heartbleed, Lucky 13, POODLE, RC4 Bias, Sweet32 …)
• verifique o comprimento dos Parâmetros Diffie Hellman pela cifra (+ cipherall necessita da opção ‘–experimental’)
• pode verificar um único atributo
• pode verificar vários alvos de uma vez
• pode ser programado (sem cabeça ou como CGI)
• deve funcionar em qualquer plataforma (só precisa de perl, openssl opcional)
• pode ser usado em ambientes CI/CD
• o formato de saída pode ser personalizado
• várias opções de rastreamento e depuração para procurar problemas de conexão incomuns
• suporta STARTTLS para vários protocolos
  • SMTP, POP3, IMAP, LDAP, RDP, XMPP, IRC (experimental) …
  • personalize sua própria sequência STARTTLS usando –starttls = ‘CUSTOM’, consulte a ajuda para ‘–starttls_phase1..5’ e ‘–starttls_error1..3’
  • sem usar o openssl
  • diminui a velocidade para evitar bloqueios de solicitações devido ao excesso de conexões (compatível com alguns protocolos como SMTP)
• O proxy é compatível (além dos comandos usando o openssl)
• verificação de STARTTLS/SMTP para todos os servidores de um registro de recurso MX (por exemplo, checkAllCiphers –mx your.tld: 25 –starttls = smtp)
• checkAllCiphers.pl e ‘+ cipherall’ suportam DTLS para uso ‘–experimental’ (se os registros não estiverem fragmentados)

sslscan – https://github.com/rbsec/sslscan

Consulta os serviços SSL/TLS, como HTTPS, para determinar as cifras que são suportadas. SSLScan foi projetado para ser fácil, enxuto e rápido. A saída inclui cifras preferenciais do serviço SSL/TLS, o certificado e a saída estão nos formatos de texto e XML. É compatível com TLS SNI quando usado com uma versão compatível do OpenSSL.

O sslscan versão 2 foi lançado. Isso inclui uma grande reescrita do código de verificação de back-end, o que significa que ele não depende mais da versão do OpenSSL para muitas verificações. Isso significa que é possível oferecer suporte a protocolos legados (SSLv2 e SSLv3), bem como a TLSv1.3 – independentemente da versão de OpenSSL com a qual foi compilado.

Isso foi possível em grande parte pelo trabalho de jtesta , que foi responsável pela maior parte da reescrita do backend.

Outras mudanças importantes incluem:

• Enumeração de grupos de troca de chaves de servidor.
• Enumeração de algoritmos de assinatura de servidor.
• O suporte aos protocolos SSLv2 e SSLv3 é verificado, mas as cifras individuais não.
• Um conjunto de testes é incluído usando o Docker, para verificar se o sslscan está funcionando corretamente.
• Removida a –httpopção, pois estava quebrada e tinha muito pouco uso em primeiro lugar.

As principais mudanças são as seguintes:

• Destaque as cifras SSLv2 e SSLv3 na saída.
• Destaque as cifras CBC em SSLv3 (POODLE).
• Destaque as cifras 3DES e RC4 na saída.
• Destaque as cifras PFS + GCM como boas na saída.
• Destaque as cifras NULL (0 bit), fracas (<40 bit) e médias (40 <n <= 56) na saída.
• Destaque as cifras anônimas (ADH e AECDH) na saída (roxo).
• Oculte as informações do certificado por padrão (exiba com –get-certificate).
• Ocultar cifras rejeitadas por padrão (exibir com –failed).
• Adicionado suporte TLSv1.1, TLSv1.2 e TLSv1.3.
• Suporta IPv6 (pode ser forçado com –ipv6).
• Verifique a compactação TLS (CRIME, desative com –no-compression).
• Desative a verificação do conjunto de criptografia –no-ciphersuites.
• Desative a saída colorida –no-colour.
• Removida a opção de saída -p não documentada.
• Adicionada verificação para OpenSSL HeartBleed (CVE-2014-0160, desabilitar com –no-heartbleed).
• Sinalize certificados assinados com MD5 ou SHA-1, ou com chaves RSA curtas (<2048 bits).
• Suporte para digitalização de servidores RDP com –rdp(credit skettler).
• Adicionada opção para especificar o tempo limite do soquete.
• Adicionada opção para compilação estática (crédito dmke).
• Adicionada –sleepopção para fazer uma pausa entre os pedidos.
• Desative a saída para qualquer coisa além das verificações especificadas –no-preferred.
• Determine a lista de CAs aceitáveis ​​para certificados de cliente –show-client-cas.
• Suporte de construção experimental no OS X (crédito MikeSchroll).
• Sinalize alguns certificados SSL autoassinados.
• Suporte experimental ao Windows (crédito jtesta).
• Exibe nomes de curvas EC e comprimentos de chave DHE com OpenSSL> = 1.0.2 –no-cipher-details.
• Sinalize chaves DHE fracas com OpenSSL> = 1.0.2 –cipher-details.
• Sinalizar certificados expirados.
• Sinalizar cifras TLSv1.0 na saída como fracas.
• Suporte experimental para OS X (apenas construção estática).
• Suporte para digitalização de servidores PostgreSQL (crédito nuxi).
• Verifique se há suporte para TLS Fallback SCSV.
• Adicionado suporte StartTLS para LDAP –starttls-ldap.
• Adicionado suporte SNI –sni-name(crédito Ken).
• Suporte STARTTLS para MySQL (crédito bk2017).
• Verifique se há grupos de troca de chaves compatíveis.
• Verifique se há algoritmos de assinatura de servidor compatíveis.

Correções de vulnerabilidade TLS

Baseado nas recomendações de  CloudFlare e Qualys SSL Labs:

1. desative todas as versões de SSL, bem como TLS 1.0 e 1.1; ativar TLS 1.2 e 1.3
2. desative a compactação de cabeçalho em TLS (SPDY 3.1 é obsoleto); TLS 1.3 não tem compressão de cabeçalho
3. desligue a cifra de stream RC4 (Rivest Cipher 4 também conhecido como ARC4 ou ARCFOUR, abreviação de Suposto RC4)
4. não permitir renegociação com clientes
5. livrar-se de cifras de exportação (isso por si só irá proteger seu servidor, por exemplo, de FREAK )
6. não permitir modos de preenchimento inseguros em TLS 1.2 (como RSA PKCS # 1 v1.5)
7. desabilite os modos CBC MAC-then-Encrypt vulneráveis ​​para proteger de Vaudenay, Lucky13, POODLE, LuckyMinus20 e outros vetores de ataque
8. ativar o suporte para TLS_FALLBACK_SCSV, uma extensão de protocolo que impede que invasores MITM forcem um downgrade de protocolo; as versões atuais do OpenSSL oferecem esse recurso fora da caixa, mas ele só funciona se o cliente e o servidor suportarem

Selecionar conjuntos de criptografia não é tão fácil quanto parece. Para obter mais informações sobre como fechar vulnerabilidades de TLS, consulte “Pacotes de criptografia TLS 1.3 (com AEAD) e TLS 1.2 desmistificados: como escolher suas criptografias com sabedoria”.

Hardening, Mitigação

CIS Controls IIS Benchmark

Visão geral

Este documento, CIS Microsoft IIS 10 Benchmark, fornece orientação prescritiva para estabelecer uma postura de configuração segura para o Microsoft IIS 10. Este guia foi testado contra o Microsoft IIS 10 rodando no Microsoft Windows Server 2016. Para obter a última versão deste guia, visite http://benchmarks.cisecurity.org. Se você tiver dúvidas, comentários ou tiver identificado maneiras de melhorar este guia, escreva-nos em [email protected].

Público-alvo

Este documento destina-se a administradores de sistemas e aplicativos, especialistas em segurança, auditores, help desk e pessoal de implantação de plataformas que planejam desenvolver, implantar, avaliar ou proteger soluções que incorporem o Microsoft IIS 10.

Orientação de Consenso

Este benchmark foi criado por meio de um processo de revisão de consenso composto por especialistas no assunto. Os participantes de consenso fornecem perspectiva de um conjunto diversificado de antecedentes, incluindo consultoria, desenvolvimento de software, auditoria e conformidade, pesquisa de segurança, operações, governo e jurídico.

Cada benchmark da CEI passa por duas fases de revisão de consenso. A primeira fase ocorre durante o desenvolvimento inicial de benchmark. Durante esta fase, os especialistas do assunto se reúnem para discutir, criar e testar rascunhos de trabalho do benchmark. Essa discussão ocorre até que se chegue a um consenso sobre as recomendações de benchmark. A segunda fase começa após a publicação do benchmark. Durante esta fase, todos os feedbacks fornecidos pela comunidade da Internet são revisados pela equipe de consenso para incorporação no benchmark. Se você estiver interessado em participar do processo de consenso, visite https://workbench.cisecurity.org/.

Criptografia de transporte

Esta seção contém recomendações para configurar protocolos IIS e suítes cifras.

Para protocolos de segurança (SSL, TLS), existem 2 caminhos de registro que controlam um estado de protocolo no servidor O/S: TLS e TLS. Um servidor web normalmente atua como o servidor TLS na medida em que está servindo conteúdo web aos clientes. Existem alguns casos em que um servidor web é configurado como um ‘cliente’. Um exemplo de servidor agindo como cliente pode ser visto quando há geração dinâmica de conteúdo. O servidor web consulta um servidor de banco de dados remoto para retornar conteúdo específico à solicitação de um usuário. Nesta configuração, o servidor web está atuando como um cliente TLS. Em casos como esses, o protocolo de servidor TLS configurado e as preferências do pacote cifrado têm precedência sobre as do cliente. Esse comportamento é o motivo pelo qual, para o benchmark IIS, exigimos configurações específicas de protocolo para um servidor TLS e apenas recomendamos configurações para clientes TLS. Se as chaves de registro SSLv3 não estiverem definidas, os padrões de O/S terão prioridade.

Por exemplo, para desativar o protocolo SSLv3 no servidor TLS, você precisa definir a seguinte chave de registro para 0:

HKLMSystemCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0ServerActivated

Para evitar que um cliente emita o comando Hello sobre esse protocolo legado, o seguinte registro deve ser definido como 0:

HKLMSystemCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0ClientActivated

O fato de que a chave se chama Enabled pode ser confuso. A definição do valor para 0 ou 1 realmente define o estado do protocolo. 0 sendo desativado e 1 sendo habilitado.

Aqui estão algumas especificidades sobre como funcionam as configurações de registro “Ativado” e “DisabledByDefault”. O artigo a seguir, Como restringir o uso de certos algoritmos e protocolos criptográficos no Schannel.dll, fornece informações adicionais relacionadas ao controle desses protocolos e cifras.

O uso da configuração de registro “Ativado = 0” desativa o protocolo de uma maneira que não pode ser substituída pelas configurações do aplicativo. Esta é a única maneira robusta de impedir que o protocolo seja usado e não são necessárias configurações adicionais. Ao mesmo tempo, o uso da configuração de registro “DisabledByDefault” só impede que esse protocolo emitindo o comando Hello sobre esse protocolo quando uma conexão SSL com um servidor é iniciada. Esta configuração de nível O/S pode ser substituída por um aplicativo que tem codificação TLS específica do aplicativo. Um exemplo disso pode ser mostrado definindo o protocolo dentro de uma linha de código em seu aplicativo .Net 4.5: ServicePointManager.SecurityProtocol =

SecurityProtocolType.Tls12. Isso pode substituir a configuração O/S se a tecla DisabledByDefault estiver presente. “DisabledByDefault” é útil no caso quando você deseja ter algum controle sobre as configurações do sistema, mas também permite que um aplicativo especifique explicitamente os protocolos que eles gostariam de usar.

Habilitado só funciona fortemente no caso negativo (“Ativado = 0”). Se “Habilitado=1” ou não for definido, então “DisabledByDefault” será substituído no caso em que o aplicativo assumir o padrão do sistema. “Enabled=1” também é substituído por bandeiras de protocolo específicas de aplicação.

7.1 (L2) Certifique-se de que o cabeçalho HSTS está definido (Não Marcado)

Aplicabilidade do perfil:

 Nível 2 – IIS 10

Descrição:

HTTP Strict Transport Security (HSTS) permite que um site informe o agente do usuário para se comunicar com o site apenas por HTTPS. Este cabeçalho tem dois parâmetros: max-age, “especifica o número de segundos, após a recepção do campo de cabeçalho STS, durante o qual o agente do usuário considera o host (de quem a mensagem foi recebida) como um Host HSTS conhecido [fala apenas HTTPS]”; e incluemSubDomains. includeSubDomains é uma diretiva opcional que define como essa política é aplicada a subdomínios. Se incluirSubDomains estiver incluído no cabeçalho, ele fornecerá a seguinte definição: esta Política HSTS também se aplica a quaisquer hosts cujos nomes de domínio são subdomínios do nome de domínio do HSTS Host conhecido.

Lógica:

HTTP Strict Transport Security (HSTS) é um padrão simples e amplamente suportado para proteger os visitantes, garantindo que seus navegadores sempre se conectem a um site sobre HTTPS. O HSTS existe para remover a necessidade da prática comum e insegura de redirecionar os usuários de http:// para https:// URLs. O HSTS conta com o Agente/Navegador do Usuário para reforçar o comportamento necessário. Todos os principais navegadores suportam isso. Se o navegador não suportar o HSTS, ele será ignorado.

Quando um navegador sabe que um domínio habilitou o HSTS, ele faz duas coisas:

1. Sempre usa uma conexão https://, mesmo clicando em um link http:// ou depois de digitar um domínio na barra de localização sem especificar um protocolo.
2. Remove a capacidade dos usuários de clicar em avisos sobre certificados inválidos.

Um domínio instrui os navegadores de que ele habilitou o HSTS retornando um cabeçalho HTTP sobre uma conexão HTTPS.

Auditoria:

A idade máxima recomendada é de 8 minutos (480 segundos) ou mais. Qualquer valor maior que 0 é aceitável. Execute o seguinte no IIS Manager para exibir cabeçalhos de host configurados para o servidor:

1. Gerente de IIS aberto
2. No painel Conexões, selecione seu servidor
3. No painel De exibição de recursos, clique duas vezes em HEADERS DE RESPOSTA HTTP
4. Verifique se existe uma entrada chamada Strict-Transport-Security
5. Clique duas vezes em Segurança de Transporte Rigoroso e verifique o Valor: a caixa contém qualquer valor superior a 0
6. Clique em OK.

Execute o seguinte no IIS Manager para exibir cabeçalhos de host configurados para o Site:

1. Gerente de IIS aberto
2. No painel Conexões, expanda a árvore e selecione Site
3. No painel De exibição de recursos, clique duas vezes em HEADERS DE RESPOSTA HTTP
4. Verifique se existe um nome De segurança de transporte rigoroso
5. Clique duas vezes em Segurança de Transporte Rigoroso e verifique o Valor: a caixa contém qualquer valor superior a 0
6. Clique em OK.

Remediação:

Qualquer valor maior que 0 atende a esta recomendação. Os exemplos abaixo são específicos de 8 minutos, mas podem ser ajustados para atender às suas necessidades.

Para definir o cabeçalho HTTP no nível do servidor usando um comando AppCmd.exe, execute o seguinte comando a partir de um prompt de comando elevado:

%systemroot%system32inetsrvappcmd.exe conjunto config –

seção:system.webServer/httpProtocol /+”customHeaders. [name=’StrictTransport-Security’,value=’max-age=480; preload’]”

Para definir o cabeçalho HTTP e incluir subdomínios no nível do servidor usando um comando AppCmd.exe, execute o seguinte comando a partir de um prompt de comando elevado:

%systemroot%system32inetsrvappcmd.exe conjunto config –

seção:system.webServer/httpProtocol /+”customHeaders. [nome=’Estritamente-

Transporte-segurança’,valor=’max-age=480; incluemSubDomains; pré-carga’]”

Para definir o cabeçalho HTTP no nível do site usando um comando AppCmd.exe, execute o seguinte comando a partir de um prompt de comando elevado:

%systemroot%system32inetsrvappcmd.exe definir config “<em>Website”</em> section:system.webServer/httpProtocol /+”customHeaders. [name=’StrictTransport-Security’,value=’max-age=480; preload’]”

Para definir o cabeçalho HTTP e incluir subdomínios no nível do Site usando um comando AppCmd.exe, execute o seguinte comando a partir de um prompt de comando elevado:

%systemroot%system32inetsrvappcmd.exe definir config “<em>Website”</em> section:system.webServer/httpProtocol /+”customHeaders. [nome=’Estritamente-

Transporte-segurança’,valor=’max-age=480; incluemSubDomains; pré-carga’]”

Referências:

1. http://tools.ietf.org/html/rfc6797#section -5.1
2. https://https.cio.gov/hsts/
3. https://www.iis.net/configreference/system.webserver/httpprotocol/customhead ers#006

Controles CIS:

Versão 7

18 Segurança do software de aplicativos

Segurança do software de aplicativos

7.2 (L1) Garantir que o SSLv2 seja desativado (pontuado)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

Este protocolo não é considerado criptograficamente seguro.

Lógica:

A desativação de protocolos fracos ajudará a garantir a confidencialidade e integridade dos dados no trânsito.

Auditoria:

Realize o seguinte para verificar se o SSL 2.0 está desativado.

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSS

L 2.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client:Enabled

2. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client:DisabledByDefault

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 2.0Server’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 2.0Client’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 2.0Server’ -name ‘DisabledByDefault’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 2.0Client’ -name ‘DisabledByDefault’

Remediação:

Realize o seguinte para desativar o SSL 2.0:

1. Definir a tecla a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client:Enabled

1. Definir a tecla a seguir está definida como ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client:DisabledByDefault

Para desativar usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols SSL 2.0Server’ -Force | Out-Null

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols SSL 2.0Client’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols

SSL 2.0Server’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols

SSL 2.0Client’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols

SSL 2.0Server’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols

SSL 2.0Client’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Valor Padrão:

Habilitado

Referências:

1. http://technet.microsoft.com/en-us/library/dn786419.aspx
2. http://technet.microsoft.com/en -us/library/dn786433.aspx
3. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
4. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.3 (L1) Garantir que o SSLv3 seja desativado (pontuado)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

Este protocolo não é considerado criptograficamente seguro. Recomenda-se desabilitá-lo.

Lógica:

A desativação de protocolos fracos ajudará a garantir a confidencialidade e integridade dos dados no trânsito.

Auditoria:

Realize o seguinte para verificar se o SSL 3.0 está desativado:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client:Enabled

2. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client:DisabledByDefault

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 3.0Server’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 3.0Client’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 3.0Server’ -name ‘DisabledByDefault’

Get-ItemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sSSL 3.0Client’ -name ‘DisabledByDefault’

Remediação:

Realize o seguinte para desativar o SSL 3.0:

1. Defina a seguinte chave para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client:Enabled

2. Definir a seguinte tecla está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client:DisabledByDefault

Para desativar usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols SSL 3.0Server’ -Force | Out-Null

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols SSL 3.0Client’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force |

Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Valor Padrão:

Habilitado

Referências:

1. https://www.openssl.org/~bodo/ssl -poodle.pdf
2. http://technet.microsoft.com/en-us/library/dn786419.aspx
3. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
4. http://technet.microsoft.com/en -us/library/dn786433.aspx
5. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.4 (L1) Garantir que o TLS 1.0 seja desativado (pontuado)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

O PCI Data Security Standard 3.1 recomenda desativar o “TLS precoce” juntamente com o SSL:

O SSL e o TLS inicial não são considerados criptografia forte e não podem ser usados como controle de segurança após 30 de junho de 2016.

Lógica:

A desativação de protocolos fracos ajudará a garantir a confidencialidade e integridade dos dados no trânsito.

Auditoria:

Realize o seguinte para verificar se o TLS 1.0 está desativado:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Client:Enabled

1. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Client:DisabledByDefault

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.0Server’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.0Client’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.0Server’ -name ‘DisabledByDefault’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.0Client’ -name ‘DisabledByDefault’

Remediação:

Realize o seguinte para desativar o TLS 1.0:

1. Defina a chave a seguir para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Client:Enabled

1. Definir a tecla a seguir está definida como ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.0Client:DisabledByDefault

Para desativar usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols TLS 1.0Server’ -Force | Out-Null

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols TLS 1.0Client’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ –

| de força Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Referências:

1. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
2. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
3. http://technet.microsoft.com/en-us/library/dn786419.aspx
4. http://technet.microsoft.com/en -us/library/dn786433.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.5 (L1) Garantir que o TLS 1.1 seja desativado (pontuado)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

O TLS 1.1 é necessário para compatibilidade retrógrada. Certifique-se de testar totalmente sua aplicação para garantir que a compatibilidade invertida não seja necessária. Se for, construa em exceções conforme necessário para retrocompatibilidade.

Lógica:

A desativação de protocolos fracos ajudará a garantir a confidencialidade e integridade dos dados no trânsito.

Auditoria:

Realize o seguinte para verificar se o TLS 1.1 está desativado:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Client:Enabled

1. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Client:DisabledByDefault

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.1Server’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.1Client’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.1Server’ -name ‘DisabledByDefault’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.1Client’ -name ‘DisabledByDefault’

Remediação:

Realize o seguinte para desativar o TLS 1.1:

1. Definir a tecla a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Server:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Client:Enabled

1. Definir a tecla a seguir está definida como ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Server:DisabledByDefault

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.1Client:DisabledByDefault

Para desativar usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols TLS 1.1Server’ -Force | Out-Null

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols TLS 1.1Client’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Cliente’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ –

| de força Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Cliente’ -name ‘DisabledByDefault’ -value ‘1’ -PropertyType ‘DWord’ Force | Out-Null

Referências:

1. http://technet.microsoft.com/en -us/library/dn786433.aspx
2. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
3. http://technet.microsoft.com/en-us/library/dn786419.aspx
4. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
5. https://community.qualys.com/thread/16565 -é-há-a-razão-para-ainda-tertlsv11-habilitado

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.6 (L1) Garantir que o TLS 1.2 esteja habilitado (Pontuado)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

O TLS 1.2 é o protocolo mais recente e maduro para proteger a confidencialidade e integridade do tráfego HTTP.

Lógica:

A habilitação deste protocolo ajudará a garantir a confidencialidade e integridade dos dados em trânsito.

Auditoria:

Execute o seguinte para verificar se o TLS 1.2 está ativado:

1. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.2Server:Enabled

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.2Server:DisabledByDefault

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.2Server’ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocol sTLS 1.2Server’ -name ‘DisabledByDefault’

Remediação:

Execute o seguinte para habilitar o TLS 1.2:

1. Defina a chave a seguir para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.2Server:Enabled

1. Definir a tecla a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTL S 1.2Server:DisabledByDefault

Para habilitar o uso do PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols TLS 1.2Server’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server’ -name ‘Enabled’ -valor ‘1’ -PropertyType ‘DWord’ -Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server’ -name ‘DisabledByDefault’ -value ‘0’ -PropertyType ‘DWord’ Force | Out-Null

Referências:

1. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
2. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
3. http://technet.microsoft.com/en-us/library/dn786419.aspx
4. http://technet.microsoft.com/en -us/library/dn786433.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.7 (L1) Garantir que as suítes de cifra NULL sejam desativadas (pontuadas)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

A cifra NULL não fornece confidencialidade ou integridade de dados. Recomenda-se que a cifra NULL seja desativada.

Lógica:

Ao desativar a cifra NULL, há uma melhor chance de manter a confidencialidade e integridade dos dados.

Auditoria:

Realize o seguinte para verificar se a cifra NULL está desativada:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL :Enabled

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNU LL’ -name ‘Enabled’

Remediação:

Realize o seguinte para desativar a cifra NULL:

1. Defina a seguinte chave para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL :Enabled

Para desativar usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNU LL’ -Force | Out-Null

Novo itemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNU LL’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Referências:

• 1. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
  2. http://technet.microsoft.com/en-us/library/dn786419.aspx
  3. http://technet.microsoft.com/en -us/library/dn786433.aspx
  4. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.8 (L1) Garantir que as suítes de cifras DES sejam desativadas (pontuadas)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

Des é uma cifra de chave simétrica fraca. Recomenda-se que seja desativado.

Lógica:

Ao desativar o DES, há uma melhor chance de manter a confidencialidade e integridade dos dados.

Auditoria:

Realize o seguinte para verificar se a cifra DES 56/56 está desativada:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56:Enabled

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56’ -name ‘Enabled’

Remediação:

Realize a seguinte cifra de DES 56/56:

1. Defina a seguinte chave para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56:Enabled

Para desativar usando o PowerShell, digite o seguinte comando:

(Get-Item ‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers’, $true). CreatesubKey (‘DES 56/56’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56’ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Referências:

• 1. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
  2. http://technet.microsoft.com/en -us/library/dn786433.aspx
  3. http://technet.microsoft.com/en-us/library/dn786419.aspx
  4. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.9 (L1) Garantir que as suítes de cifra RC4 sejam desativadas (pontuadas)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

RC4 é uma cifra de fluxo que tem conhecido ataques práticos. Recomenda-se que o RC4 seja desativado. A única cifra RC4 habilitada por padrão no Server 2012 e 2012 R2 é RC4 128/128.

Lógica:

O uso do RC4 pode aumentar a capacidade dos adversários de ler informações confidenciais enviadas pelo SSL/TLS.

Auditoria:

Realize o seguinte para verificar RC4 40/128, RC4 56/128, RC4 64/128, RC4 128/128 cifras foram desativadas.

1. Certifique-se de que as seguintes teclas estão definidas para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4

40/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4

64/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128:Enabled

Para verificar usando o PowerShell, digite os seguintes comandos:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC

4 40/128′ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC

4 56/128′ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC

4 64/128′ -name ‘Enabled’

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC 4 128/128’ -name ‘Enabled’

Remediação:

Realize o seguinte para desativar RC4 40/128, RC4 56/128, RC4 64/128, RC4 128/128 cifras:

1. Defina as seguintes teclas para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4

56/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4

64/128:Enabled

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128:Enabled

Para desativar usando o PowerShell, digite os seguintes comandos:

(Get-Item

‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHA NNELCiphers’, $true). CreatesubKey (‘RC4 40/128’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC

4 40/128′ -name ‘Enabled’ -valor ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

(Get-Item

‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHA NNELCiphers’, $true). CreatesubKey (‘RC4 56/128’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC 4 56/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

(Get-Item

‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHA NNELCiphers’, $true). CreatesubKey (‘RC4 64/128’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC 4 64/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

(Get-Item

‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHA NNELCiphers’, $true). CreatesubKey (‘RC4 128/128’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC 4 128/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Referências:

1. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
2. http://technet.microsoft.com/en -us/library/dn786433.aspx
3. http://technet.microsoft.com/en-us/library/dn786419.aspx
4. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.10 (L1) Garantir que a suíte cifrada AES 128/128 seja desativada (pontuada)

Aplicabilidade do perfil:

• Nível 1 – IIS 10

Descrição:

A habilitação do AES 128/128 pode ser necessária para a compatibilidade do cliente. Habilite ou desabilita esta suíte cifrada em conformidade.

Lógica:

Este item é pontuado pelas seguintes razões e deve ser desativado:

• Recomenda-se a habilitação do AES 256/256.
• Esta cifra não sofre de ataques práticos conhecidos.

Auditoria:

Realize o seguinte para verificar se a cifra AES 128/128 está desativada:

1. Certifique-se de que a chave a seguir está definida para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 128/128:Enabled

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAE S 128/128’ -name ‘Enabled’

Remediação:

Realize o seguinte para desativar a cifra AES 128/128:

1. Defina a seguinte chave para ₀.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 128/128:Enabled

Para desativar usando o PowerShell, digite o seguinte comando:

(Get-Item ‘HKLM:’). OpenSubKey(‘SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCifras’, $true). CreatesubKey (‘AES 128/128’)

Caminho do Novo ItemProperty

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAE S 128/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

Referências:

1. http://technet.microsoft.com/en-us/library/dn786419.aspx
2. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
3. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
4. http://technet.microsoft.com/en -us/library/dn786433.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.11 (L1) Garantir que a suíte cifrada AES 256/256 esteja habilitada (Pontuada)

Aplicabilidade do perfil:

 Nível 1 – IIS 10

Descrição:

A AES 256/256 é a mais recente e madura suíte de cifras para proteger a confidencialidade e integridade do tráfego HTTP. Recomenda-se a habilitação do AES 256/256. Isso é habilitado por padrão no Server 2012 e 2012 R2.

Lógica:

A habilitação dessa cifra ajudará a garantir a confidencialidade e integridade dos dados em trânsito.

Auditoria:

Realize o seguinte para verificar se está habilitada a cifra AES 256/256:

1. Certifique-se de que a chave a seguir está definida para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 256/256:Enabled

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAE S 256/256’ -name ‘Enabled’

Remediação:

Execute o seguinte para habilitar a cifra AES 256/256:

1. Defina a seguinte tecla para ₁.

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 256/256:Enabled

Para desativar usando o PowerShell, digite o seguinte comando:

(Get-Item ‘HKLM:’). OpenSubKey (‘SYSTEMCurrentControlSetControlSecurityProvidersSCHA NNELCiphers’, $true). CreatesubKey (‘AES 256/256’)

Novo itemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAE S 256/256’ -name ‘Enabled’ -value ‘1’ -PropertyType ‘DWord’ -Force | Out-Null

Referências:

• 1. http://technet.microsoft.com/en-us/library/dn786419.aspx
  2. http://msdn.microsoft.com/en -us/library/aa374757%28v=vs.85%29.aspx
  3. https://www.owasp.org/index.php/Testing_for_SSL -TLS_%28OWASP-CM-001%29
  4. http://technet.microsoft.com/en -us/library/dn786433.aspx

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

7.12 (L2) Certifique-se de que o pedido do TLS Cipher Suite está configurado (Pontuado)

Aplicabilidade do perfil:

 Nível 2 – IIS 10

Descrição:

As suítes cifras são uma combinação nomeada de autenticação, criptografia, código de autenticação de mensagens e algoritmos de troca de chaves usados para as configurações de segurança de uma conexão de rede usando o protocolo TLS. Os clientes enviam uma lista de cifras e uma lista de cifras que ele suporta por ordem de preferência a um servidor. Em seguida, o servidor responde com o conjunto cifrado que ele seleciona na lista de suítes cifras do cliente.

Lógica:

As suítes cifradas devem ser encomendadas do mais forte ao mais fraco, a fim de garantir que a configuração mais segura seja usada para criptografia entre o servidor e o cliente.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Evite trajes cifrados que não forneçam o Perfect Forward Secrecy ou usem a função de hash fraca, use-os apenas se você precisar suportar a compatibilidade para trás e na parte inferior da lista e você terá que criar exceções para os itens que fazem com que isso fique fora de conformidade:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (usa SHA-1)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (usa SHA-1)

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (usa SHA-1) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (usa SHA-1)

TLS_RSA_WITH_AES_256_GCM_SHA384 (falta de segredo perfeito para a frente)

TLS_RSA_WITH_AES_128_GCM_SHA256 (falta de segredo perfeito para a frente)

TLS_RSA_WITH_AES_256_CBC_SHA256 (falta de Segredo perfeito para a frente)

TLS_RSA_WITH_AES_128_CBC_SHA256 (falta de Segredo perfeito para a frente)

TLS_RSA_WITH_AES_256_CBC_SHA (usa SHA-1, falta de Segredo perfeito para a frente)

TLS_RSA_WITH_AES_128_CBC_SHA (usa SHA-1, falta de Segredo perfeito para a frente)

Nota: Compatibilidade HTTP/2: as primeiras 4 cifras (em negrito) na lista de partes superiores são compatíveis com HTTP/2

Auditoria:

Execute o seguinte para verificar se a ordem do pacote de cifras TLS está configurada corretamente:

1. Certifique-se de que a seguinte chave está definida para

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GC

M_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_1

28_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_W

ITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ RSA_WITH_AES_128_CBC_SHA256.

HKLMSOFTWAREPoliciesMicrosoftCryptographyConfiguraçãoSSL0010002:Functions

Para verificar usando o PowerShell, digite o seguinte comando:

Get-ItemProperty -path

‘HKLM:SOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL0010002’ name ‘Functions’

Remediação:

Execute o seguinte para configurar o pedido de suíte de cifras TLS:

1. Defina a seguinte chave para

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GC

M_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_1

28_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_W ITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ RSA_WITH_AES_128_CBC_SHA256.

HKLMSOFTWAREPoliciesMicrosoftCryptographyConfiguraçãoSSL0010002:Functions

Para configurar a ordem do pacote de cifras TLS usando o PowerShell, digite o seguinte comando:

Novo item

‘HKLM:SOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL0010002’ Force | Out-Null

Caminho do Novo ItemProperty

‘HKLM:SOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL0010002’ nome ‘Functions’ -value

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA

256.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA2

56.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_S

HA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.TLS_ECDHE_RSA_WITH_AES_128_CBC_SH

A256′ -PropertyType ‘MultiString’ -Force | Out-Null

Impacto:

O pedido de cifra é importante para garantir que as cifras mais seguras sejam listadas primeiro e sejam aplicadas sobre cifras mais fracas quando possível.

Controles CIS:

Versão 7

14.4 Criptografe todas as informações confidenciais em trânsito Criptografe todas as informações confidenciais em trânsito.

Traduzido e adaptado de:

TLS Security 1

Saiba o que é SSL/TLS, onde é usado e por que foi introduzido.

TLS Security 2

Conheça a história do SSL/TLS e versões de protocolo: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2.

TLS Security 3

Saiba mais sobre terminologia e noções básicas SSL/TLS, por exemplo, algoritmos de criptografia, suítes cifrada, autenticação de mensagens e muito mais.

TLS Security 4

Conheça os certificados TLS/SSL, as autoridades de certificados e como gerar certificados.

TLS Security 5

Saiba como uma conexão TLS é estabelecida, incluindo troca de chaves, apertos de mão TLS e muito mais.

TLS Security 6

Conheça as vulnerabilidades e ataques da TLS, como POODLE, BEAST, CRIME, BREACH e Heartbleed.

 

https://www.cloudinsidr.com/content/known-attack-vectors-against-tls-implementation-vulnerabilities/