Diferenças surpreendentes entre o protocolo TLS e SSL - Anonymous Hacker

[Latest News][10]

Análise de Vulnerabilidade
ANDROID
ANONYMOUS
ANTI-DDOS
ANTI-SPYWARES E ADWARES
APK PRO
APOSTILAS
CIÊNCIA
CURSO PHP
CURSO TCP / IP
CURSOS
CYBORG
CYBORG FALÇÃO
DDOS
DEEPWEB
DICAS
DOCUMENTARIO
DoS
EXPLOIT
FACEBOOK
Ferramentas de rede
FORENSE DIGITAL
INVASÕES
IPHONE
JOGOS
KALI LINUX
Lixão
MAC OS
Malware
MySQL
NOTÍCIAS
PAGINA FAKE
PHP SCRIPT
Programa De Invasao
PROGRAMAÇÃO
PROGRAMAS
PROXY
SCRIPTS
SEGURANÇA
SHELL
SISTEMA OPERACIONAL
TÉCNICA DE INVASÃO
Termux
VIDEOS
VPN
WHATSAPP
WINDOWS
Wireless Attacks
z=

Diferenças surpreendentes entre o protocolo TLS e SSL

Diferenças surpreendentes entre o protocolo TLS e SSL

O TLS é simplesmente um sucessor do SSL 3.0, o TLS é um protocolo que fornece criptografia de dados e integridade entre os canais de comunicação. O SSL 3.0 é servido como base para o TLS 1.0.

SSL ou TLS O que é bom?

Nós acreditamos que o TLS 1.0 é um Sucessor do SSL 3.0. Como sabemos, o SSL3.0 é muito antigo e ataques recentes como POODLE, BEAST e outros vetores de ataque tornaram o SSL3.0 sem vida como um protocolo de segurança.
Devido ao ataque POODLE, o SSL v3 está sendo completamente desativado em sites de todo o mundo.
Em seguida, o ataque BEAST que quebra completamente os sites em execução nos protocolos SSL v3.0 e TLS v1.0 mais antigos.
Infelizmente ainda alguns dos sites não usam TLS, você pode verificar a configuração do seu site usando o analisador Comodo SSL .

Protocolo de Handshake TLS

Quando um cliente e servidor TLS começam a se comunicar pela primeira vez, eles concordam com uma versão de protocolo, selecionam algoritmos criptográficos, autenticam-se opcionalmente e usam técnicas de criptografia de chave pública para gerar segredos compartilhados.
O protocolo TLS Handshake envolve as seguintes etapas:
  1. Troque mensagens de saudação para concordar com algoritmos, trocar 
    valores aleatórios e verificar a retomada da sessão.
  2. Troque os parâmetros criptográficos necessários para permitir que o 
    cliente e o servidor concordem com um segredo pré-mestre.
  3. Troque certificados e informações criptográficas para permitir que o 
    cliente e o servidor os autentiquem.
  4. Gere um segredo mestre do segredo pré-mestre e troque 
    valores aleatórios.
  5. Fornecer parâmetros de segurança para a camada de gravação.
  6. Permita que o cliente e o servidor verifiquem se seus pares 
    calcularam os mesmos parâmetros de segurança e se o handshake 
    ocorreu sem adulteração por um invasor.
Diferenças surpreendentes entre o protocolo TLS e SSL

Notificações de protocolo TLS e SSL

Se algum problema for encontrado na conexão, qualquer uma das partes que descobrir o problema acionará uma mensagem de alerta. Você pode encontrar alguns certificados SSL curingas baratos aqui.

Descrições de alertas SSL

Close_Notify
Esta mensagem notifica o destinatário de que o remetente não enviará mais mensagens nessa conexão.
Mensagem_exibida
Uma mensagem inapropriada foi recebida. Esse alerta é sempre fatal e nunca deve ser observado na comunicação entre implementações adequadas.
Bad_record_mac
Este alerta é retornado se um registro é recebido com um MAC incorreto. Esse alerta será retornado se um alerta for enviado porque um TLSCiphertext foi descriptografado de uma maneira inválida: ou não era um múltiplo par do tamanho do bloco ou seus valores de preenchimento, quando 
marcados, não estavam corretos.
Decryption_failed_RESERVED
Esse alerta foi usado em algumas versões anteriores do TLS e pode ter permitido determinados ataques contra o modo CBC.
Record_overflow
Um registro TLSCiphertext foi recebido com mais de 2 ^ 14 + 2048 bytes, ou um registro descriptografado em um registro TLSCompressed com mais de 2 ^ 14 + 1024 bytes.
Falha de descompressão
A função de descompressão recebeu entrada imprópria (por exemplo, dados que se expandiram para tamanho excessivo). Esta mensagem é sempre fatal e nunca deve ser observada na comunicação entre implementações adequadas.
A função de descompressão recebeu entrada imprópria (por exemplo, dados que se expandiram para tamanho excessivo). Esta mensagem é sempre fatal e nunca deve ser observada na comunicação entre implementações adequadas.
Handshake_failure
A recepção de uma mensagem de alerta handshake_failure indica que o remetente não conseguiu negociar um conjunto aceitável de parâmetros de segurança, dadas as opções disponíveis. Este é um erro fatal.
No_certificate_RESERVED
Esse alerta foi usado no SSLv3, mas não em qualquer versão do TLS. NÃO DEVE ser enviado por implementações compatíveis.
Bad_certificate
Um certificado estava corrompido, continha assinaturas que não foram verificadas corretamente, etc.
Unsupported_certificate
Um certificado era de um tipo não suportado.
Certificate_revoked
Um certificado foi revogado por seu signatário.

Alerta adicional de TLS Descrições

Certificate_expired
Um certificado expirou ou não é válido no momento.
Certificate_unknown
Algum outro problema (não especificado) surgiu no processamento do certificado, tornando-o inaceitável.
Illegal_parameter
Um campo no handshake estava fora do intervalo ou inconsistente com outros campos. Essa mensagem é sempre fatal.
Unknown_ca
Uma cadeia de certificados válida ou cadeia parcial foi recebida, mas o certificado não foi aceito porque o certificado da autoridade de certificação não pôde ser localizado ou não pôde ser correspondido com uma CA confiável e conhecida. Essa mensagem é sempre fatal.
Acesso negado
Um certificado válido foi recebido, mas quando o controle de acesso foi aplicado, o remetente decidiu não prosseguir com a negociação. Essa mensagem é sempre fatal.
Decode_error
Uma mensagem não pôde ser decodificada porque algum campo estava fora do intervalo especificado ou o tamanho da mensagem estava incorreto. Esta mensagem é sempre fatal e nunca deve ser observada na comunicação entre implementações adequadas (exceto quando as mensagens estiverem corrompidas na rede).
Decrypt_error
Uma operação criptográfica de handshake falhou, incluindo a impossibilidade de verificar corretamente uma assinatura ou validar uma mensagem Finished. Essa mensagem é sempre fatal.
Export_restriction_RESERVED
Este alerta foi usado em algumas versões anteriores do TLS. NÃO DEVE ser enviado por implementações compatíveis.
Protocol_version
A versão do protocolo que o cliente tentou negociar é reconhecida, mas não suportada. (Por exemplo, versões antigas de protocolo podem ser evitadas por motivos de segurança.) Essa mensagem é sempre fatal.
Insufficient_security
Retornado em vez de handshake_failure quando uma negociação falhou especificamente porque o servidor requer cifras mais seguras que as suportadas pelo cliente. Essa mensagem é sempre fatal.
Erro interno
Um erro interno não relacionado ao par ou a correção do protocolo (como uma falha de alocação de memória) torna impossível continuar. Essa mensagem é sempre fatal.
User_canceled
Este aperto de mão está sendo cancelado por algum motivo não relacionado a uma falha do protocolo. Se o usuário cancelar uma operação após o término do handshake, é mais apropriado fechar a conexão enviando um close_notify. Este alerta deve ser seguido por um close_notify. Esta mensagem é geralmente um aviso.
No_renegotiation
Enviado pelo cliente em resposta a um pedido de hello ou pelo servidor em resposta a um cliente hello após o handshaking inicial. Qualquer um desses normalmente levaria a renegociação; quando isso não for apropriado, o destinatário deve responder com este alerta. Nesse ponto, o solicitante original pode decidir se deseja prosseguir com a conexão.
Um caso em que isso seria apropriado é quando um servidor gerou um processo para satisfazer uma solicitação; o processo pode receber parâmetros de segurança (tamanho da chave, autenticação, etc.) na inicialização e pode ser difícil comunicar alterações a esses parâmetros após esse ponto. Esta mensagem é sempre um aviso.
Extensão não suportada
enviado por clientes que recebem um servidor estendido ola contendo uma extensão que eles não colocaram no cliente correspondente hello. Essa mensagem é sempre fatal.

Compatibilidade com TLS e SSL

Como existem várias versões do TLS (1.0, 1.1, 1.2 e quaisquer versões futuras) e SSL (2.0 e 3.0), são necessários meios para negociar a versão específica do protocolo a ser usada.
O protocolo TLS fornece um mecanismo interno para negociação de versão, de modo a não incomodar outros componentes do protocolo com as complexidades da seleção de versões.
 Um cliente TLS 1.2 que deseja negociar com esses servidores mais antigos enviará um TLS 1.2 ClientHello normal, contendo {3, 3} (TLS 1.2) em ClientHello.client_version.
Se o servidor não suportar esta versão, ele responderá com um ServerHello contendo um número de versão mais antigo. Se o cliente concordar em usar esta versão, a negociação prosseguirá conforme apropriado para o protocolo negociado
Se um servidor TLS receber um ClientHello contendo um número de versão maior que a versão mais alta suportada pelo servidor, ele DEVE responder de acordo com a versão mais alta suportada pelo servidor.
Por exemplo, se o servidor suportar TLS 1.0, 1.1 e 1.2, e client_version for TLS 1.0, o servidor continuará com um TLS 1.0 ServerHello. Se o servidor suportar (ou estiver disposto a usar) somente versões maiores que client_version, ele DEVE enviar uma mensagem de alerta “protocol_version” e fechar a conexão.
Sempre que um cliente já conhece a versão de protocolo mais alta conhecida para um servidor (por exemplo, ao retomar uma sessão), ele deve iniciar a conexão nesse protocolo nativo.
Tenho certeza que existem várias outras funções e diferença mais do que isso, para mais informações sobre o protocolo TLS Atributos e funções que você pode se referir  RFC5246 .

Sobre

trabalho com segurança da informação a 13 anos, grande parte desse tempo como professor. Fiz meu bacharelado em ciência da computação, especialização em segurança da informação e logo após, mestrado em ciência da informação.

Nenhum comentário:

Postar um comentário

Start typing and press Enter to search