Geral

SSL (e seu sucessor, TLS ) é um protocolo que opera diretamente em cima do TCP (embora também haja implementações para protocolos baseados em datagramas, como UDP). Desta forma, os protocolos em camadas superiores (como HTTP) podem ser deixados inalterados enquanto s até fornecer uma conexão segura. Abaixo da camada SSL, o HTTP é idêntico ao HTTPS.

Ao usar SSL / TLS corretamente, tudo o que um invasor pode ver no cabo é a qual IP e porta você está conectado, aproximadamente a quantidade de dados que você está enviando e qual criptografia e compactação são usadas. Ele também pode encerrar a conexão, mas ambos os lados saberão que a conexão foi interrompida por um terceiro.

No uso normal, o invasor também será capaz de descobrir a qual nome de host você está se conectando (mas não o resto do URL): embora HTTPS em si não exponha o nome do host, seu navegador geralmente precisará fazer uma solicitação DNS primeiro para descobrir para qual endereço IP enviar a solicitação.

Alta – descrição de nível do protocolo

Depois de construir uma conexão TCP, o handshake SSL é iniciado pelo cliente. O cliente (que pode ser um navegador, bem como qualquer outro programa, como Windows Update ou PuTTY) envia uma série de especificações:

• qual versão de SSL / TLS está em execução,
• o que ciphersuites ele deseja usar e
• o que métodos de compactação que deseja usar.

O servidor identifica a versão SSL / TLS mais alta suportada por ele e pelo cliente, escolhe um ciphersuite de uma das opções do cliente (se for compatível) e, opcionalmente, escolhe um método de compactação.

Após fazer a configuração básica, o servidor envia seu certificado. Este certificado deve ser confiável para o próprio cliente ou uma parte em que o cliente confie. Por exemplo, se o cliente confia no GeoTrust, ele pode confiar no certificado do Google.com porque o certificado do Google do GeoTrust assinado criptograficamente .

Após verificar o certificado e ter certeza de que este servidor realmente é quem afirma ser (e não um intermediário), uma chave é trocada. Pode ser uma chave pública, a ” PreMasterSecret ” ou simplesmente nada, dependendo do ciphersuite escolhido. Tanto o servidor quanto o cliente agora podem calcular a chave para o criptografia simétrica ^{whynot PKE?} . O cliente informa ao servidor que a partir de agora, todas as comunicações serão criptografadas, e envia uma mensagem criptografada e autenticada para o servidor.

O servidor verifica se o MAC (usado para autenticação) está correto e se a mensagem pode ser descriptografada corretamente. Em seguida, retorna uma mensagem, que o cliente verifica como bem.

O handshake está concluído e os dois hosts podem se comunicar com segurança. Para obter mais informações, consulte technet.microsoft.com/en-us/library/cc785811 e en.wikipedia .org / wiki / Secure_Sockets_Layer .

Para fechar a conexão, um “alerta” close_notify é usado. Se um invasor tentar encerrar a conexão finalizando a conexão TCP (injetando um pacote FIN), ambos os lados saberão que a conexão foi encerrada incorretamente. A conexão não pode ser comprometida por isso, apenas interrompida.

Mais alguns detalhes

Por que você pode confiar no Google.com confiando no GeoTrust?

Um site deseja se comunicar com você de forma segura. Para provar sua identidade e certificar-se de que não é um invasor, você deve ter a “s chave pública do servidor. No entanto, você dificilmente pode armazenar todas as chaves de todos os sites do planeta, o banco de dados seria enorme e as atualizações teriam que ser executadas a cada hora!

A solução para isso são as autoridades de certificação, ou CA, abreviadamente.Quando você instalou seu sistema operacional ou navegador, uma lista de CAs confiáveis provavelmente veio com ele. Esta lista pode ser modificada à vontade; você pode remover quem não confia, adicionar outras pessoas ou até mesmo fazer sua própria CA (embora você seja o único que confia nessa CA, por isso não é muito útil para um site público). Nesta lista de CA, a chave pública da CA também é armazenada.

Quando o servidor do Google lhe envia seu certificado, ele também menciona que ele é assinado pela GeoTrust. Se você confia no GeoTrust, você pode verificar (usando a chave pública do GeoTrust) se o GeoTrust realmente assinou o certificado do servidor. Para assinar um certificado você mesmo, você precisa da chave privada, que só é conhecida pelo GeoTrust. Dessa forma, um invasor não pode assinar um certificado e alegar ser Google.com incorretamente. Quando o certificado for modificado por um bit, mesmo que seja, o sinal ficará incorreto e o cliente irá rejeitá-lo.

Portanto, se eu souber a chave pública, o servidor pode provar sua identidade?

Sim. Normalmente, a chave pública criptografa e a chave privada descriptografa. Criptografe uma mensagem com a chave pública do servidor, envie-a e, se o servidor puder repetir a mensagem original, isso apenas provará que obteve a chave privada sem revelar a chave.

É por isso que é tão importante poder confiar na chave pública: qualquer um pode gerar um par de chaves privada / pública, também um invasor. Você não quer acabar usando a chave pública de um invasor!

Se Se uma das CAs em que você confia está comprometida, um invasor pode usar a chave privada roubada para assinar um certificado para qualquer site de sua preferência. Quando o invasor pode enviar um certificado forjado para seu cliente, assinado por ele mesmo com a chave privada de uma CA em que você confia, seu cliente não sabe que a chave pública é forjada, assinada com uma chave privada roubada.

Mas uma CA pode me fazer confiar em qualquer servidor que eles quiserem!

Sim, e é aí que vem a confiança in. Você tem que confiar na CA para não fazer certificados como eles desejam. Porém, quando organizações como a Microsoft, Apple e Mozilla confiam em uma CA, a CA deve ter auditorias; outra organização verifica periodicamente para ter certeza de que tudo ainda está funcionando de acordo às regras.

A emissão de um certificado é feita se, e somente se, o registrante puder provar que é o proprietário do domínio para o qual o certificado foi emitido.

O que é este MAC para autenticação de mensagem?

Cada mensagem é assinada com um denominado Código de autenticação de mensagem ou MAC para abreviar. Se concordarmos com uma chave e criptografia de hash, você pode verificar se minha mensagem vem de mim e eu posso verificar se sua mensagem vem de você.

Por exemplo, com a chave ” grampo correto da bateria do cavalo ” e a mensagem ” exemplo “, Posso calcular o MAC ” 58393 “. Quando eu envio esta mensagem com o MAC para você (você já conhece a chave), você pode realizar a mesma computação e comparar o MAC calculado com o MAC que enviei.

Um invasor pode modificar a mensagem mas não conhece a chave. Ele não pode calcular o MAC correto e você saberá que a mensagem não é autêntica.

Ao incluir um número de sequência ao calcular o MAC, você pode eliminar a repetição ataques . SSL faz isso.

Você disse que o cliente envia uma chave, que é então usada para configurar criptografia simétrica. O que impede que um invasor a use?

A chave pública do servidor sim. Como verificamos que a chave pública realmente pertence ao servidor e a mais ninguém, nós pode criptografar a chave usando a chave pública. Quando o servidor a recebe, ele pode descriptografá-la com a chave privada. Quando qualquer outra pessoa a recebe, não pode descriptografá-la.

É também por isso que o tamanho da chave é importante: Quanto maior for a chave pública e privada, mais difícil é quebrar a chave que o cliente envia para o servidor.

Como quebrar SSL

Resumindo :

• Tente se o usuário ignora avisos de certificado;
• O aplicativo pode carregar dados de um canal não criptografado (por exemplo, HTTP), que pode ser adulterado;
• Uma página de login desprotegida que envia para HTTPS pode ser modificada para que seja enviada para HTTP;
• Aplicativos sem patch podem ser vulnerável a exploits como BEAST e CRIME;
• Recorrer a outros métodos como h como um ataque físico;
• Explorar canais secundários como o comprimento da mensagem e o tempo usado para formar a mensagem;
• Aguarde ataques quânticos .

Veja também: Um esquema com muitos vetores de ataque contra SSL por Ivan Ristic ^(png)

Em detalhes:

Não há nada simples e direto maneira; SSL é seguro quando feito corretamente. No entanto, um invasor pode tentar se o usuário ignorar avisos de certificado , o que quebraria a segurança instantaneamente. Quando um usuário faz isso, o invasor não precisa de uma chave privada de uma CA para forjar um certificado, ele apenas precisa enviar um certificado próprio.

Outra maneira seria por uma falha no aplicativo (servidor ou cliente). Um exemplo fácil é em sites: se um dos recursos usados pelo site (como uma imagem ou um script) for carregado em HTTP, a confidencialidade não pode mais ser garantida. Mesmo que os navegadores não envie o cabeçalho HTTP Referer ao solicitar recursos não seguros de uma página segura ( fonte ), ainda é possível que alguém espionando o tráfego para adivinhar onde você “está visitando de; por exemplo, se eles souberem que as imagens X, Y e Z são usadas em uma página, eles podem adivinhar que você está visitando essa página quando virem seu navegador solicitar essas três imagens de uma vez. Além disso, ao carregar o Javascript, toda a página pode ser comprometida. Um invasor pode executar qualquer script na página, modificando, por exemplo, para quem a transação bancária irá.

Quando isso acontece (um recurso sendo carregado por HTTP), o navegador fornece um aviso de conteúdo misto: Chrome , Firefox , Internet Explorer 9

Outro truque para HTTP é quando a página de login não está protegida e é enviada para uma página https. ” Ótimo, ” o desenvolvedor provavelmente pensou, ” agora eu salvo a carga do servidor e o a senha ainda é enviada criptografada! ” O problema é sslstrip , uma ferramenta que modifica a página de login insegura para que envia em algum lugar para que o invasor possa lê-lo.

Também houve vários ataques nos últimos anos, como a vulnerabilidade de renegociação de TLS , sslsniff , BEAST e, muito recentemente, CRIME . Todos os navegadores comuns são protegidos contra todos esses ataques, portanto, essas vulnerabilidades não são riscos se você estiver executando um navegador atualizado.

Por último, mas não menos importante, você pode recorrer a outros métodos para obter as informações que SSL nega que você obtenha. Se você já pode ver e adulterar a conexão do usuário, pode não ser tão difícil substituir um de seus downloads .exe por um keylogger ou simplesmente atacar fisicamente essa pessoa. A criptografia pode ser bastante segura, mas humanos e o erro humano ainda é um fator fraco. De acordo com este documento da Verizon , 10% das violações de dados envolveram ataques físicos (consulte a página 3), então ” certamente é algo para se ter em mente.

Comentários

• Eu estaria interessado em mais algumas explicações para ” uma chave é trocada ” pela chave simétrica. Como isso acontece quando alguém com um farejador de pacotes não consegue acessar.
• @Yehosef Boa pergunta! Esqueci de explicar isso na minha resposta. Olhando em volta, descobrimos que na verdade há uma pergunta dedicada a isso: security.stackexchange.com/q/6290/10863
• @ Iwazaru: Todos os CAs fazem isso desde o primeiro dia. O objetivo de um certificado é fornecer a chave pública para um determinado domínio e assiná-lo para provar que realmente é a chave certa para o domínio. Vamos ‘ s Encrypt está fazendo exatamente o que deveria fazer: verificar se você é o proprietário do domínio e assinar seu certificado (com sua chave), se puder provar. Agora, todos que confiam em Let ‘ s Encrypt, que é praticamente todos os navegadores, confiarão nesse certificado.
• Er, não. O TLS é, de fato, implementado apenas no topo do TCP.
• Este processo gráfico de handshake SSL foi encontrado, muito claro.

Visto que o conceito geral de SSL já foi abordado em algumas outras perguntas (por exemplo, este e aquele ), desta vez irei para obter detalhes. Os detalhes são importantes. Esta resposta será um tanto prolixa.

História

SSL é um protocolo com uma longa história e várias versões.Os primeiros protótipos vieram do Netscape quando eles estavam desenvolvendo as primeiras versões de seu navegador principal, o Netscape Navigator (este navegador eliminou Mosaic nos primeiros tempos das Guerras dos Navegadores, que ainda estão acontecendo, embora com novos concorrentes). A versão 1 nunca foi tornada pública, então não sabemos como era. A versão 2 do SSL é descrita em um rascunho que pode ser lido lá ; ele tem uma série de pontos fracos, alguns deles bastante sérios, por isso está obsoleto e as implementações SSL / TLS mais recentes não o suportam (embora as mais antigas sejam desativadas por padrão). Não falarei mais sobre o SSL versão 2, exceto como uma referência ocasional.

O SSL versão 3 (que chamarei de “SSLv3”) era um protocolo aprimorado que ainda funciona hoje e é amplamente suportado. Embora ainda seja propriedade da Netscape Communications (ou de quem o possui atualmente), o protocolo foi publicado como um “RFC histórico” ( RFC 6101 ). Enquanto isso, o protocolo foi padronizado, com um novo nome para evitar questões legais; o novo nome é TLS .

Três versões de TLS foram produzidas até agora, cada uma com seu RFC dedicado: TLS 1.0 , TLS 1.1 e TLS 1.2 . Eles são internamente muito semelhantes entre si e com SSLv3, a ponto de uma implementação poder facilmente suportar SSLv3 e todas as três versões de TLS com pelo menos 95% do código sendo comum. Ainda assim, internamente, todas as versões são designadas por um número de versão com o formato major.minor ; SSLv3 é então 3.0, enquanto as versões TLS são, respectivamente, 3.1, 3.2 e 3.3. Portanto, não é de se admirar que o TLS 1.0 às vezes seja chamado de SSL 3.1 (e também não é incorreto). SSL 3.0 e TLS 1.0 diferem apenas por alguns detalhes minuciosos. TLS 1.1 e 1.2 ainda não são amplamente suportados, embora haja um impulso para isso, por causa de possíveis pontos fracos (veja abaixo, para o “ataque BEAST”). SSLv3 e TLS 1.0 são suportados “em todos os lugares” (até o IE 6.0 os conhece).

Contexto / h1>

O SSL visa fornecer um túnel bidirecional seguro para dados arbitrários. Considere o TCP , o protocolo conhecido para envio de dados pela Internet. O TCP funciona sobre os “pacotes” IP e fornece um túnel bidirecional para bytes; ele funciona para todos os valores de byte e os envia para dois fluxos que podem operar simultaneamente. O TCP lida com o trabalho árduo de dividir os dados em pacotes, reconhecendo-os, remontando-os de volta na ordem certa, enquanto remove duplicatas e reemite pacotes perdidos. Do ponto de vista da aplicação que usa TCP, existem apenas dois fluxos e os pacotes são invisíveis; em particular, os streams não são divididos em “mensagens” (cabe ao aplicativo seguir suas próprias regras de codificação se desejar ter mensagens, e é exatamente isso que HTTP faz).

O TCP é confiável na presença de “acidentes”, ou seja, erros de transmissão devido a hardware fragmentado, congestionamento de rede, pessoas com smartphones que saem do alcance de uma determinada estação base e outros eventos não maliciosos. No entanto, um indivíduo mal intencionado (o “invasor”) com algum acesso ao meio de transporte pode ler todos os dados transmitidos e / ou alterá-los intencionalmente, e o TCP não protege contra isso. SSL.

O SSL assume que funciona sobre um protocolo semelhante ao TCP, que fornece um fluxo confiável; o SSL não implementa a reemissão de pacotes perdidos e coisas assim. O invasor é supostamente no poder de interromper a comunicação completamente de uma maneira inevitável (por exemplo, ele pode cortar os cabos), então o trabalho do SSL é:

• detectar alterações (o invasor não deve ser capaz de alterar os dados silenciosamente );
• garantir a confidencialidade dos dados (o o invasor não deve obter conhecimento dos dados trocados).

O SSL cumpre esses objetivos em grande escala (mas não absoluta).

Registros

SSL é colocado em camadas e a camada inferior é o protocolo de registro . Quaisquer dados enviados em um túnel SSL são divididos em registros . Na rede (o soquete TCP subjacente ou meio semelhante ao TCP), um registro se parece com este:

HH V1:V2 L1:L2 data

onde:

• HH é um único byte que indica o tipo de dados no registro.Quatro tipos são definidos: change_cipher_spec (20), alert (21), handshake (22) e application_data ( 23).
• V1: V2 é a versão do protocolo, com mais de dois bytes. Para todas as versões atualmente definidas, V1 tem valor 0x03, enquanto V2 tem valor 0x00 para SSLv3, 0x01 para TLS 1.0, 0x02 para TLS 1.1 e 0x03 para TLS 1.2.
• L1: L2 é o comprimento de data, em bytes (a convenção big-endian é usado: o comprimento é 256 * L1 + L2). O comprimento total de data não pode exceder 18.432 bytes, mas na prática, não pode nem atingir esse valor.

Portanto, um registro tem cinco cabeçalho de byte, seguido por no máximo 18 kB de dados. O data é onde a criptografia simétrica e as verificações de integridade são aplicadas. Quando um registro é emitido, o remetente e o receptor devem concordar sobre quais algoritmos criptográficos são aplicados atualmente e com quais chaves; esse acordo é obtido por meio do protocolo de handshake, descrito na próxima seção. A compactação, se houver, também é aplicada nesse ponto.

Em todos os detalhes, a construção de um registro funciona assim:

• Inicialmente, há alguns bytes para transferir ; esses são dados do aplicativo ou algum outro tipo de bytes. Esta carga consiste em no máximo 16384 bytes, mas possivelmente menos (uma carga útil de comprimento 0 é legal, mas acontece que o Internet Explorer 6.0 não gosta disso de forma alguma ) .
• A carga útil é então compactada com qualquer algoritmo de compactação acordado atualmente. A compactação tem estado e, portanto, pode depender do conteúdo de registros anteriores. Na prática, a compactação é “nula” (nenhuma compactação) ou “Deflate” ( RFC 3749 ), a última sendo mostrada de maneira cortês, mas firme, a saída porta no contexto da Web, devido ao recente ataque CRIME . A compactação visa encurtar os dados, mas deve necessariamente expandi-los ligeiramente em algumas situações desfavoráveis (devido ao princípio do escaninho ). SSL permite uma expansão de, no máximo, 1024 bytes. Obviamente, a compactação nula nunca se expande (mas também nunca diminui); Deflate se expandirá em no máximo 10 bytes se a implementação for boa.
• A carga compactada é então protegida contra alterações e criptografada. Se os algoritmos atuais de criptografia e integridade forem “nulos”, esta etapa não é uma operação. Caso contrário, um MAC é anexado, então algum preenchimento (dependendo do algoritmo de criptografia) e o resultado é criptografado. Essas etapas novamente induzem alguma expansão, que o padrão SSL limita a 1024 bytes extras (combinada com a expansão máxima da etapa de compactação, isso nos leva a 18432 bytes, aos quais devemos adicionar o cabeçalho de 5 bytes).

O MAC é, geralmente, HMAC com uma das funções hash usuais (principalmente MD5, SHA-1 ou SHA-256) (com SSLv3, este não é o “verdadeiro” HMAC, mas algo muito semelhante e, até onde sabemos, tão seguro quanto o HMAC). A criptografia usará uma cifra de bloco no modo CBC ou a cifra de fluxo RC4 . Observe que, em teoria, outros tipos de modos ou algoritmos podem ser empregados, por exemplo, um desses modos bacanas que combinam criptografia e verificações de integridade; há até alguns RFC para isso . Na prática, porém, as implementações implantadas ainda não sabem disso, então fazem HMAC e CBC. Crucialmente, o MAC é primeiro calculado e anexado aos dados, e o resultado é criptografado. Isso é criptografado pelo MAC e, na verdade, não é uma ideia muito boa . O MAC é calculado sobre a concatenação da carga (compactada) e um número de sequência, de modo que um invasor diligente não possa trocar registros.

Handshake

O handshake é um protocolo que é reproduzido dentro do protocolo de gravação. Seu objetivo é estabelecer os algoritmos e chaves que devem ser usados para os registros. Consiste em mensagens . Cada mensagem de handshake começa com um cabeçalho de quatro bytes, um byte que descreve o tipo de mensagem e três bytes para o comprimento da mensagem (convenção big-endian). As mensagens de handshake sucessivas são então enviadas com registros marcados com o tipo “handshake” (o primeiro byte do cabeçalho de cada registro tem valor 22).

Observe as camadas: as mensagens de handshake, completas com quatro- cabeçalho de byte, são então enviados como registros, e cada registro também tem seu próprio cabeçalho. Além disso, várias mensagens de handshake podem ser enviadas dentro do mesmo registro, e uma determinada mensagem de handshake pode ser dividida em vários registros.Do ponto de vista do módulo que constrói as mensagens de handshake, os “registros” são apenas um fluxo no qual os bytes podem ser enviados; ele ignora a divisão real desse fluxo em registros.

Full Handshake

Inicialmente, o cliente e o servidor “concordam” com a criptografia nula sem MAC e compactação nula. Isso significa que o registro que eles enviarão primeiro será enviado como texto não criptografado e desprotegido.

A primeira mensagem de um handshake é um ClientHello. É a mensagem pela qual o cliente declara sua intenção de fazer algum SSL. Observe que “cliente” é um papel simbólico; significa “a parte que fala primeiro”. Acontece que no contexto HTTPS, que é HTTP-dentro-SSL-dentro-TCP, todas as três camadas têm uma noção de “cliente” e “servidor”, e todas elas concordam (o cliente TCP também é o cliente SSL e o cliente HTTP), mas isso “é uma espécie de coincidência.

A mensagem ClientHello contém:

• o protocolo máximo versão que o cliente deseja suportar;
• o “cliente aleatório” (32 bytes, dos quais 28 devem ser gerados com um gerador de números criptograficamente forte);
• o ” ID de sessão “(caso o cliente queira retomar uma sessão em um handshake abreviado, veja abaixo);
• a lista de” conjuntos de criptografia “que o cliente conhece, ordenada por preferência do cliente;
• a lista de algoritmos de compactação que o cliente conhece, ordenados por preferência do cliente;
• algumas extensões opcionais.

A cipher suite é um identificador simbólico de 16 bits para um conjunto de criptografias algoritmos c. Por exemplo, o pacote de criptografia TLS_RSA_WITH_AES_128_CBC_SHA tem o valor 0x002F e significa que “os registros usam criptografia HMAC / SHA-1 e AES com uma chave de 128 bits e a troca de chaves é feita por criptografia uma chave aleatória com a “chave pública RSA do servidor”.

O servidor responde ao ClientHello com um ServerHello que contém:

• a versão do protocolo que o cliente e o servidor usarão ;
• o “servidor aleatório” (32 bytes, com 28 bytes aleatórios);
• o ID da sessão para esta conexão;
• o pacote de criptografia que será usado;
• o algoritmo de compactação que será usado;
• opcionalmente, algumas extensões.

O handshake completo tem a seguinte aparência:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Este esquema foi descaradamente copiado do RFC.)

Vemos ClientHello e ServerHello. Em seguida, o servidor envia algumas outras mensagens, que dependem do pacote de criptografia e alguns outros parâmetros rs:

• Certificado: o certificado do servidor, que contém sua chave pública. Mais sobre isso abaixo. Essa mensagem quase sempre é enviada, exceto se o pacote de criptografia exige um handshake sem um certificado.
• ServerKeyExchange: alguns valores extras para a troca de chaves, se o que está no certificado não for suficiente. Em particular, os pacotes de criptografia “DHE” usam uma troca de chaves Diffie-Hellman efêmera, que requer essa mensagem.
• CertificateRequest: uma mensagem solicitando que o cliente também se identifique com um certificado próprio. Esta mensagem contém a lista de nomes de âncoras de confiança (também conhecidas como “certificados raiz”) que o servidor usará para validar o certificado do cliente.
• ServerHelloDone: uma mensagem de marcador (de comprimento zero) que diz que o servidor terminou e o cliente deve falar agora.

O cliente deve então responder com:

• Certificado: o certificado do cliente, se o servidor solicitou um. Existem variações sutis entre as versões (com SSLv3, o cliente deve omitir esta mensagem se não tiver um certificado; com TLS 1.0+, na mesma situação, deve enviar um Certificate mensagem com uma lista vazia de certificados).
• ClientKeyExchange: a parte do cliente da troca de chaves real (por exemplo, algum valor aleatório criptografado com a chave RSA do servidor).
• CertificateVerify: a assinatura digital calculada pelo cliente sobre todas as mensagens de handshake anteriores. Essa mensagem é enviada quando o servidor solicitou um certificado de cliente e o cliente atendeu. É assim que o cliente prova ao servidor que realmente “possui” a chave pública que está codificada no certificado que enviou.

Em seguida, o cliente envia um ChangeCipherSpec mensagem, que não é uma mensagem de handshake: ela tem seu próprio tipo de registro, portanto, será enviada em um registro próprio.Seu conteúdo é puramente simbólico (um único byte de valor 1). Essa mensagem marca o ponto em que o cliente alterna para o conjunto de criptografia e as chaves recém-negociadas. Os registros subsequentes do cliente serão criptografados.

A mensagem Concluída é uma soma de verificação criptográfica calculada sobre todas as mensagens de handshake anteriores (do cliente e do servidor). Visto que é emitido após o ChangeCipherSpec, também é coberto pela verificação de integridade e criptografia. Quando o servidor recebe essa mensagem e verifica seu conteúdo, obtém uma prova de que de fato conversou com o mesmo cliente o tempo todo. Esta mensagem protege o handshake de alterações (o invasor não pode modificar as mensagens de handshake e ainda obter a Finished mensagem correta).

O servidor finalmente responde com sua própria ChangeCipherSpec e Finished. Nesse ponto, o handshake é concluído e o cliente e o servidor podem trocar dados do aplicativo (em registros criptografados marcados como tal).

Para lembrar: o cliente sugere , mas o servidor escolhe . O pacote de criptografia está nas mãos do servidor. Servidores corteses devem seguir as preferências do cliente (se possível), mas eles podem fazer o contrário e alguns realmente fazem (por exemplo, como parte da proteção contra BEAST).

Aperto de mão abreviado

No handshake completo, o servidor envia uma “ID de sessão” (ou seja, um grupo de até 32 bytes) para o cliente. Mais tarde, o cliente pode voltar e enviar o mesmo ID de sessão como parte de seu ClientHello. Isso significa que o cliente ainda se lembra do conjunto de criptografia e das chaves do handshake anterior e gostaria de reutilizar esses parâmetros. Se o servidor também lembrar o pacote de criptografia e as chaves, ele copia esse ID de sessão específico em seu ServerHello e segue o handshake abreviado :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

O handshake abreviado é mais curto: menos mensagens, não negócio de criptografia assimétrica e, mais importante, latência reduzida . Os navegadores e servidores da Web fazem muito isso. Um navegador da Web típico abrirá uma conexão SSL com um handshake completo e, em seguida, realizará handshakes abreviados para todas as outras conexões com o mesmo servidor: as outras conexões que ele abre em paralelo e também as conexões subsequentes com o mesmo servidor. Na verdade, os servidores da Web típicos fecharão as conexões após 15 segundos de inatividade, mas se lembrarão das sessões (o pacote de criptografia e as chaves) por muito mais tempo (possivelmente por horas ou mesmo dias).

Troca de chaves

Existem vários algoritmos de troca de chaves que SSL pode usar. Isso é especificado pelo conjunto de criptografia; cada algoritmo de troca de chave funciona com alguns tipos de chave pública de servidor. Os algoritmos de troca de chave mais comuns são:

• RSA: a chave do servidor “é do tipo RSA. O cliente gera um valor aleatório (o” segredo pré-mestre “de 48 bytes, dos quais 46 são aleatórios) e criptografa-o com a chave pública do servidor. Não há ServerKeyExchange.
• DHE_RSA: a chave do servidor é do tipo RSA, mas usada apenas para assinatura. A troca de chaves real usa Diffie-Hellman. O servidor envia uma ServerKeyExchange mensagem contendo os parâmetros DH (módulo, gerador) e uma chave pública DH recém-gerada; além disso, o servidor assina esta mensagem. O cliente responderá com uma ClientKeyExchange mensagem que também contém uma chave pública DH recém-gerada. O DH produz o “segredo pré-mestre “.
• DHE_DSS: como DHE_RSA, mas o servidor tem uma chave DSS (” DSS “também é conhecido como “DSA” ). DSS é um algoritmo apenas de assinatura.

Os algoritmos de troca de chaves menos comumente usados incluem:

• DH: a chave do servidor é do tipo Diffie-Hellman (estamos falando de um certificado que contém um Chave DH). Isso costumava ser “popular” de forma administrativa (o governo federal dos Estados Unidos determinou seu uso) quando a patente RSA ainda estava ativa (isso foi durante o século anterior). Apesar do esforço burocrático, ele nunca foi tão amplamente implantado quanto o RSA.
• DH_anon: como os DHE suites, mas sem a assinatura do servidor. Este é um pacote de criptografia sem certificado. Por construção, ele é vulnerável a ataques man-in-the-middle , portanto, muito raramente ativado.
• PSK: chave pré-compartilhada . A troca de chave simétrica apenas, baseada em um segredo compartilhado pré-estabelecido.
• SRP: a aplicação do protocolo SRP que é um Protocolo de troca de chaves autenticadas por senha . O cliente e o servidor autenticam-se mutuamente em relação a um segredo compartilhado, que pode ser uma senha de baixa entropia (enquanto o PSK requer um segredo compartilhado de alta entropia). Muito bacana. Ainda não é amplamente suportado.
• Uma chave RSA efêmera: como DHE, mas com um par de chaves RSA recém-gerado. Como a geração de chaves RSA é cara, esta não é uma opção popular e foi especificada apenas como parte dos conjuntos de criptografia de “exportação” que estavam em conformidade com as regulamentações de exportação dos EUA anteriores a 2000 sobre criptografia (ou seja, chaves RSA de no máximo 512 bits). Ninguém faz isso hoje em dia.
• Variantes dos DH* algoritmos com curvas elípticas . Muito chique. Deve se tornar comum no futuro.

Certificados e autenticação

Certificados digitais são recipientes para chaves assimétricas. Eles se destinam a resolver a distribuição de chaves. A saber, o cliente deseja usar a chave pública do servidor. O invasor tentará fazer o cliente usar a chave pública do invasor . Portanto, o cliente deve ter uma maneira de certificar-se de que está usando a chave certa.

O SSL deve usar X.509 . Este é um padrão para certificados. Cada certificado é assinado por uma Autoridade de Certificação . A ideia é que o cliente conheça inerentemente as chaves públicas de um punhado de CA (essas são as “âncoras de confiança” ou “certificados raiz”). Com essas chaves, o cliente pode verificar a assinatura computada por uma CA em um certificado que foi emitido para o servidor. Este processo pode ser estendido recursivamente: uma CA pode emitir um certificado para outra CA (ou seja, assinar a estrutura do certificado que contém o nome e a chave da outra CA). Uma cadeia de certificados começando com uma CA raiz e terminando com o certificado do servidor, com certificados CA intermediários entre eles, cada certificado sendo assinado em relação à chave pública que está codificada no certificado anterior, é chamada, sem imaginação, de cadeia de certificados .

Portanto, o cliente deve fazer o seguinte:

• Obter uma cadeia de certificados terminando com o certificado do servidor. A Certificate mensagem do servidor deve conter, precisamente, essa cadeia.
• Validar a cadeia, ou seja, verificar todos os assinaturas e nomes e os vários bits X.509. Além disso, o cliente deve verificar o status de revogação de todos os certificados na cadeia, que é complexo e pesado (navegadores da Web agora fazem isso, mais ou menos, mas é um desenvolvimento recente).
• Verifique se o nome do servidor pretendido está realmente escrito no certificado do servidor. Como o cliente não deseja apenas usar uma chave pública validada, ele também deseja usar a chave pública de um servidor específico . Consulte RFC 2818 para obter detalhes sobre como isso é feito em um contexto HTTPS .

O modelo de certificação com certificados X.509 tem sido frequentemente criticado, não por motivos técnicos, mas sim por razões político-econômicas. Ele concentra o poder de validação nas mãos de alguns jogadores , que não são necessariamente bem-intencionados, ou pelo menos nem sempre competentes . De vez em quando, propostas para outros sistemas são publicadas (por exemplo, Convergência ou

Depois a longa apresentação de SSL na resposta anterior , vamos com a parte divertida, a saber:

Ataques em SSL

Houve muitos ataques em SSL, alguns baseados em erros de implementação, outros em verdadeiras fraquezas de protocolo.

Deve-se lembrar que embora o SSL seja um dos protocolos mais atacados (já que é de alto perfil: uma aplicação bem-sucedida para SSL parece muito boa no resumo de um artigo de pesquisa), SSL também é um dos protocolos mais reparados .Deve ser considerado robusto precisamente porque todas as formas conhecidas de atacar protocolos de transporte foram experimentadas em SSL, e SSL foi corrigido onde apropriado.

Reversão de versão

Nos primeiros dias do SSLv3, SSLv2 ainda era amplamente usado e, portanto, os clientes costumavam enviar compatível com SSLv2 ClientHello mensagens, que apenas indicavam que SSLv3 também era suportado; o servidor então pegaria a dica e responderia no dialeto SSLv3 + (consulte o Apêndice E de RFC 2246 para obter detalhes). Visto que SSLv2 tinha pontos fracos, era do interesse do invasor providenciar que um cliente e um servidor, ambos conhecendo SSLv3, conversassem entre si usando SSLv2. Isso é chamado de ataque de reversão de versão . O conceito também se estende formalmente a versões posteriores.

Kludges foi adicionado para detectar tentativas de reversão. Para reversões back-to-SSLv2, um cliente que conhece SSLv3 + deve empregar um preenchimento especial para a etapa de criptografia RSA (SSLv2 é compatível apenas com a troca de chave baseada em RSA): em PKCS # 1 , os dados que devem ser criptografados devem ser preenchidos com um número de bytes aleatórios; um cliente compatível com SSLv3 deve definir cada um dos últimos oito bytes de preenchimento com o valor fixo 0x03. O servidor então verifica esses bytes; se os oito 0x03 forem encontrados, então um rollback é provavelmente tentado, e o servidor rejeita a tentativa (um cliente somente SSLv2 tem probabilidade de apenas 255 ^-8 de usar tais bytes de preenchimento por pura falta de sorte, então falsos positivos ocorrem em uma taxa insignificante).

Para reversões para uma versão antiga de SSL / TLS, mas não anterior a SSLv3, outro kludge foi adicionado: no segredo pré-mestre de 48 bytes que o cliente criptografa com a chave RSA do servidor, os primeiros dois bytes não são aleatórios, mas devem ser iguais à “versão máxima de protocolo suportada” que o cliente escreveu primeiro em seu ClientHello mensagem. Infelizmente, alguns clientes entenderam errado, e este kludge funciona apenas com uma troca de chave baseada em RSA, então a proteção contra reversão é muito limitada. Felizmente, SSLv3 + tem outra proteção muito mais poderosa contra rollbacks, que significa que as mensagens de handshake são misturadas quando as Finished mensagens são criadas. Este profissional protege contra rollbacks, a menos que a “versão antiga” seja tão fraca que o invasor possa quebrar totalmente a criptografia antes do fim do próprio handshake. Isso ainda não aconteceu (SSLv3 ainda é razoavelmente robusto).

Suítes de criptografia fracas

Alguns dos conjuntos de criptografia padrão são intencionalmente fracos de alguma forma. Existem:

• alguns conjuntos de criptografia sem criptografia, apenas verificação de integridade, por exemplo, TLS_RSA_WITH_NULL_SHA;
• alguns pacotes de criptografia com criptografia de 40 bits, como TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (pacotes de criptografia destinados a cumprir as rígidas regras de exportação dos EUA do século passado – essas regulamentações foram suspensas principalmente no final da era Bill Clinton);
• alguns conjuntos de criptografia com criptografia de 56 bits, como TLS_RSA_WITH_DES_CBC_SHA. DES de 56 bits é quebrável com a tecnologia existente , mas isso ainda é um pouco difícil para um amador (até mesmo um estudante entediado com acesso a algumas centenas de máquinas universitárias ), portanto, tendo a qualificar DES de 56 bits como “força média”.

Isso abre o caminho para uma variante dos ataques de reversão de versão, em que o invasor força o cliente e o servidor a concordarem em um pacote de criptografia fraco, a ideia é que o invasor modifique a lista de pacotes de criptografia anunciados pelo cliente. Isso é viável para o invasor se o pacote de criptografia selecionado for tão fraco que ele pode quebrá-lo para recomputar um Finished mensagem. Na verdade, o MAC usado em SSLv3 + (mesmo quando baseado em MD5) é robusto o suficiente para evitar isso. Portanto, não se preocupe aqui. Além disso, minha opinião é que qualquer fraqueza real aqui é quando um cliente ou servidor aceita usar um pacote de criptografia fraco.

Por padrão, os navegadores da Web modernos não permitem o uso de tais pacotes de criptografia fracos.

Roubo de chave privada

Se uma conexão SSL usa troca de chave RSA, e um invasor mantém uma cópia dos registros e, em seguida, mais tarde (possivelmente meses depois, possivelmente inspecionando todos os backups em discos rígidos ou fitas descartados) obtém uma cópia da chave privada, então ele pode desvendar o aperto de mão e descriptografar os dados.

Perfect Forward Secrecy trata de combater isso “mais tarde”. Você pode obtê-lo usando os DHE conjuntos de criptografia. Com um conjunto de criptografia DHE, a chave privada real que pode ser usada para desvendar o handshake é a chave Diffie-Hellman efêmera, não a chave privada RSA (ou DSS) do servidor.Sendo efêmero, ele existia apenas na RAM e nunca foi gravado no disco rígido; como tal, deve ser muito mais resistente a roubos ulteriores.

Portanto, a lição é: como regra, tente usar um conjunto de criptografia DHE, se possível. Você ainda deve cuidar de seus backups e não permitir que sua chave privada vaze, mas, pelo menos, os conjuntos de DHE tornam esse vazamento um pouco menos problemático, especialmente se acontecer após o fim da vida útil da chave (ou seja, o certificado correspondente não mais válidos).

Problemas com certificados

Todo o negócio de certificados é um ponto sensível em SSL.

Tecnicamente, SSL é bastante independente do X.509. As cadeias de certificados são trocadas como blobs opacos. Em algum ponto, o cliente deve usar a chave pública do servidor, mas o cliente está livre para “conhecer” essa chave da maneira que achar adequada. Em alguns cenários específicos onde SSL pode ser usado, o cliente já conhece o servidor “s chave pública (codificada no código) e apenas ignora o certificado enviado pelo servidor. No entanto, no caso comum de HTTPS, o cliente faz a validação da cadeia de certificados do servidor, conforme descrito em X.509 ( leia às custas de sua sanidade; você foi avisado).

Isso produz uma série de vetores de ataque, por exemplo:

• A validação envolve verificar se os certificados ainda são válidos na data atual. Como a máquina cliente sabe a data atual? Com seu relógio interno, e possivelmente conversando com servidores NTP (em de uma forma bastante desprotegida!). O cliente pode ficar atrasado por vários minutos, horas, dias, até anos (eu já vi) e, até certo ponto, um invasor poderoso poderia forçá-lo mexendo nas mensagens NTP. Isso permitiria o invasor deve usar certificados obsoletos que foram revogados anos atrás. Observe um fato engraçado: o SSL “client random” e “server random” deve conter 28 bytes aleatórios e a data e hora local (mais de 4 bytes). Esta inclusão de tempo foi criado para ser parte de uma solução alternativa contra ataques baseados em tempo. Não tenho conhecimento de nenhuma implementação que realmente verifique isso.

• Até cerca de 2003, a implementação de validação de certificado no Internet Explorer / Windows não processava a extensão “Restrições básicas” apropriadamente. O efeito líquido foi que qualquer pessoa com um certificado de 100 € poderia atuar como um CA e emitir “certificados” com nome e chaves escolhidos arbitrariamente.

• X .509 inclui um recurso de contenção de danos chamado revogação : trata-se da publicação de uma lista de certificados banidos, que parecem bons, criptograficamente falando, mas não devem ser confiáveis (por exemplo, sua chave privada foi roubada ou contêm um nome errado). A revogação funciona apenas na medida em que as partes envolvidas (ou seja, navegadores) aceitem baixar listas gigantescas de revogação (que podem ter vários megabytes!) Ou entrar em contato com servidores OCSP . Os navegadores modernos agora fazem isso, mas com um pouco de relutância, e muitos aceitarão se conectar de qualquer maneira se não puderem obter informações sobre o status de revogação em tempo hábil (porque o usuário humano não é paciente). A situação geral melhora com o passar dos anos, mas muito lentamente.

• Alguns CA raiz cometeram alguns erros no passado (por exemplo, Comodo e DigiNotar). Isso resultou na emissão de certificados falsos (o nome é www.microsoft.com, mas a chave privada não está nas mãos da Microsoft …). Esses erros foram descobertos e os certificados revogados, mas ainda levanta algumas questões desconfortáveis (por exemplo, há outra CA que teve esses problemas, mas não os revelou ou, pior ainda, nunca os notou?).

X.509 é uma montagem muito complexa de algoritmos, tecnologias, especificações e comitês, e é muito difícil acertar. Tentar decodificar certificados X.509 “manualmente” em uma linguagem de programação desprotegida como C é uma maneira fácil de obter estouros de buffer.

Ataques Bleichenbacher

Daniel Bleichenbacher encontrou em 1998 um belo ataque contra RSA. Quando você criptografa um dado com RSA (como ocorre para a mensagem ClientKeyExchange em SSL), os dados a serem criptografados devem ser preenchidos em ordem para fazer uma sequência de bytes do mesmo comprimento que o módulo RSA. O preenchimento consiste principalmente em bytes aleatórios, mas há um pouco de estrutura (notavelmente, os primeiros dois bytes após o preenchimento devem ser 0x00 0x02).

Após a descriptografia (no servidor, então), o preenchimento deve ser encontrado e removido. Acontece que, naquele momento, quando o servidor descriptografou, mas obteve um preenchimento inválido (os bytes 0x00 0x02 não estavam lá), ele relatou isso com uma mensagem de alerta (conforme a especificação SSL), enquanto um preenchimento válido resultou em o servidor usando o valor aparentemente descriptografado e continuando com o handshake.

Esse tipo de coisa é conhecido como oráculo de preenchimento . Ele permite que um invasor envie uma sequência arbitrária de bytes como se fosse um segredo pré-mestre criptografado e saiba se a descriptografia dessa sequência produziria um preenchimento válido ou não. Isso é apenas uma informação de 1 bit, mas é suficiente para recuperar a chave privada com alguns milhões de solicitações (com strings “criptografadas” habilmente criadas).

Solução alternativa: quando a descriptografia resulta em um inválido preenchimento, o servidor continua usando um segredo pré-mestre aleatório. O handshake falhará mais tarde, com as mensagens Finished. Todas as implementações atuais de SSL fazem isso.

O oráculo de preenchimento contra-ataca

Outra área onde um oráculo de preenchimento foi encontrado é no os próprios registros. Considere a criptografia CBC e HMAC. Os dados a criptografar são primeiro codificados por MAC e, em seguida, o resultado é criptografado. Com a criptografia CBC, os dados a serem criptografados devem ter um comprimento múltiplo do tamanho do bloco (8 bytes para 3DES, 16 bytes para AES). Então, algum padding é aplicado, com alguma estrutura.

Naquela época (o ataque foi descoberto por Vaudenay em 2002), quando uma implementação de SSL estava processando um recebimento d registro, ele retornou mensagens de alerta distintas para estas duas condições:

• Após a descriptografia, nenhuma estrutura de preenchimento válida foi encontrada.
• Após a descriptografia, um preenchimento válido foi encontrado, mas o MAC foi verificado e não correspondia.

Este é um oráculo de preenchimento e pode ser usado para recuperar alguns dados criptografados. Requer um atacante ativo, mas não é tão difícil. Vaudenay o implementou, e foi estendido para o caso em que uma implementação SSL modificada retornou a mesma mensagem de alerta em ambos os casos, mas demorou mais para retornar no segundo caso, por causa do tempo que leva para recalcular o MAC (uma boa demonstração de um ataque de cronometragem ).

Como as pessoas nunca aprendem, a implementação da Microsoft do SSL usado no ASP.NET foi ainda sem correção em 2010 (oito anos depois!), quando Rizzo e Duong reimplementaram o ataque Vaudenay e construíram uma demonstração que recuperou cookies HTTP.

Veja esta página para algumas dicas. Deve-se notar que se SSL tivesse usado encrypt-then-MAC , tais problemas teriam sido evitados (os registros defeituosos teriam sido rejeitados no nível MAC, antes mesmo considerando a descriptografia).

BEAST

O ataque BEAST é novamente de Duong e Rizzo, e, novamente, é um remake de um ataque antigo (de Philip Rogaway em 2002). Para ter uma ideia, considere CBC . Neste modo de operação, cada bloco de dados é primeiro XORed com o resultado da criptografia do bloco anterior; e esse é o resultado do XOR que é criptografado. Isso é feito para “randomizar” os blocos e evitar os vazamentos que são encontrados com o modo ECB. Já que o primeiro bloco não tem um bloco “anterior”, deve haver um Vetor de inicialização (IV), que desempenha a função do bloco anterior para o primeiro bloco.

Acontece que se um invasor pode controlar parte dos dados que devem ser criptografados, e também pode prever o IV que será usado, então ele pode transformar a máquina de criptografia em mais uma descriptografia oracle e usá-lo para recuperar alguns outros dados criptografados (que o invasor não escolhe). No entanto, em SSLv3 e TLS 1.0, o invasor pode prever o IV para um registro: é o último bloco de o registro anterior! Portanto, o invasor deve ser capaz de enviar alguns dados no fluxo, a fim de “empurrar” os dados de destino, em um ponto onde a implementação construiu e enviou o registro anterior (normalmente quando vale 16 kB de dados foram acumulados), mas não começou a construir o próximo.

TLS 1.1+ é protegido contra isso porque no TLS 1.1 (e versões subsequentes), um IV aleatório por registro é usado. Para SSLv3 e TLS 1.0, uma solução alternativa é enviar registros de comprimento zero: ou seja, registros com uma carga útil de comprimento zero – mas com um MAC e preenchimento e criptografia, e o MAC é calculado a partir de uma chave secreta e sobre a sequência número, portanto, ele desempenha o papel de um gerador de números aleatórios. Infelizmente, o IE 6.0 bloqueia em registros de comprimento zero. Outras estratégias envolvem uma divisão 1 / n-1 (um registro de n bytes é enviado como dois registros, um com um único byte de carga útil, o outro com os n-1 ).

Outra solução alternativa é forçar o uso de um pacote de criptografia não CBC quando possível – o servidor seleciona um pacote de criptografia baseado em RC4 se houver um na lista de pacotes de criptografia enviada pelo cliente, mesmo se o cliente preferisse um pacote de criptografia baseado em CBC. Esta ferramenta pode dizer se um determinado servidor aparentemente age assim.(Observação: BEAST é um ataque ao cliente , mas, ao selecionar um pacote de criptografia RC4, o servidor pode proteger um cliente descuidado.)

Consulte esta página para algumas dicas. Embora o TLS 1.1 seja de 2006, o ataque BEAST pode forçar os fornecedores do navegador a finalmente atualizar.

CRIME

Como para qualquer franquia de Hollywood, Duong e Rizzo publicaram em 2012 a sequência da sequência. O CRIME explora um vazamento que foi teorizado anos atrás, mas que só foi vividamente demonstrado na demonstração que publicaram recentemente. O CRIME explora a compressão, na mesma configuração do ataque BEAST (o invasor pode enviar alguns dados próprios em uma conexão SSL, para a qual dados de destino interessantes, como um cookie, também são enviados). Grosso modo, o invasor coloca em seus dados um valor potencial para a string de destino e, se corresponder, a compactação torna os registros resultantes mais curtos. Veja esta questão para uma análise (pré-cognitiva).

O CRIME é evitado por não usar compressão de nível TLS, o que é o que os navegadores agora fazem. Em primeiro lugar, o Internet Explorer e o IIS nunca implementaram a compactação de nível TLS (pela primeira vez, a negligência salvou o dia); O Firefox e o Chrome o implementaram e desativaram neste verão (eles foram avisados por Duong e Rizzo, que são bastante responsáveis em suas atividades).

O CRIME mostra porque escrevi, perto do início do meu Explicações sobre SSL :

O SSL cumpre esses objetivos em grande medida (mas não absoluta).

Na verdade, a criptografia vaza o comprimento dos dados criptografados. Não existe uma boa solução conhecida contra isso. E o comprimento por si só pode revelar muitas coisas. Por exemplo, ao observar com um monitor de rede uma conexão SSL, podemos detectar os “apertos de mão extras” dentro do fluxo (porque o primeiro byte de cada registro identifica o tipo de dados no registro e não é criptografado); com os comprimentos dos registros, é muito fácil ver se o cliente forneceu um certificado ou não.

Poodle

( edit: esta seção foi adicionada em 2014-10-15)

O ataque “Poodle” explora uma falha específica do SSL 3.0 com pacotes de criptografia baseados em CBC. Ele se baseia em um recurso frequentemente esquecido do SSL 3.0: a maioria dos bytes de preenchimento são ignorados. No TLS 1.0, o preenchimento (bytes adicionados em um registro para tornar o comprimento compatível com a criptografia CBC, que processa apenas blocos completos) é totalmente especificado; todos os bytes devem ter um valor específico e o destinatário verifica isso. No SSL 3.0, o conteúdo do byte de preenchimento é ignorado, o que permite que um invasor faça alterações que passam despercebidas. A alteração afeta apenas dados não-aplicativos, mas pode ser usada como um oráculo de descriptografia de uma forma vagamente semelhante ao BEAST.

Mais detalhes podem ser lidos neste responda .

O futuro

Os humanos nunca aprendem. Há muita pressão para adicionar extensões bacanas ao SSL por muitos motivos que sempre parecem bons no início, mas podem induzir problemas extras.

Considere, por exemplo, SSL FalseStart . Principalmente, trata-se de o cliente enviar os dados do aplicativo logo após ter enviado sua Finished mensagem (em um handshake completo), sem esperar pelo Finished mensagem do servidor. Isso reduz a latência, o que é bom e bem-intencionado. No entanto, isso muda a situação de segurança: antes de ter recebido a mensagem Finished do servidor, este é apenas implicitamente autenticado (o cliente ainda não tem provas de que o servidor pretendido estava realmente envolvido em all; ele apenas sabe que tudo o que enviar será lido apenas pelo servidor pretendido). Isso pode ter impactos; por exemplo, um invasor pode emular o servidor até aquele ponto e forçar, por exemplo, o cliente a usar um pacote de criptografia baseado em CBC ou compressão TLS. Portanto, se um cliente implementar FalseStart, isso diminuirá a eficácia das medidas de proteção contra BEAST e CRIME, como poderia ser aplicado pelo servidor.

(Google desativou FalseStart nesta primavera, aparentemente por causa de problemas de compatibilidade com alguns servidores. De qualquer forma, a “redução de latência de 30%” parecia estranha, porque FalseStart teria alguma influência apenas em handshakes completos, não abreviados, então eu não ” não acredite nesses supostos benefícios; não dessa magnitude, pelo menos.)

Comentários

• A quantidade de esforço que você faz para fornecer boas informações por meio este site é realmente louco e extremamente admirável. Muito apreciado.
• Veja também tools.ietf.org / html / rfc7457