Por que é uma boa prática comparar somas de verificação ao baixar um arquivo?

16

Os sites que fornecem arquivos ISO para download geralmente fornecem as somas de verificação md5 desses arquivos, que podemos usar para confirmar que o arquivo foi baixado corretamente e que não foi corrompido.

Por que isso é necessário? Certamente, as propriedades de correção de erros do TCP são suficientes. Se um pacote não for recebido corretamente, ele será retransmitido. A própria natureza de uma conexão TCP / IP não garante a integridade dos dados?

tcp

— Aditya K
fonte

10

Além disso, não se esqueça dos possíveis erros no software e no hardware que fazem a transferência de dados, nos pontos de extremidade como também entre eles.

— sebix

O download pode ter terminado alguns bytes mais cedo. Você não notaria necessariamente pelo tamanho do arquivo, a menos que esteja prestando atenção, e a correção de erros do TCP só teria verificado a parte dos dados que realmente chegaram.

— Kevin Keane

As somas de verificação podem ser úteis, mas, em 20 anos trabalhando com computadores, não me lembro de usá-la uma vez.

— Pedro Lobito

2

MD5 são hashes, não somas de verificação. Uma soma de verificação é usada para verificar se há erros, especificamente erros de bits durante a transmissão. Um hash criptográfico destina-se a garantir que os dados sejam exatamente os mesmos. Nesse sentido, um hash seria um superconjunto de soma de verificação, mas não é o mesmo. Além disso, o MD5 está quebrado há 10 anos (consulte o artigo da Wikipedia, seção Segurança ).

— 0xC0000022L

20

Como já foi observado por outros, existem muitas possibilidades de corrupção de dados em que qualquer soma de verificação na camada de transporte não pode ajudar, como corrupção ocorrendo antes do cálculo da soma de verificação no lado do envio, um MITM interceptando e modificando o fluxo (dados também como somas de verificação), corrupção ocorrendo após a validação da soma de verificação na extremidade receptora etc.

Se desconsiderarmos todas essas outras possibilidades e focarmos nas especificidades da própria soma de verificação TCP e no que ela realmente faz em termos de validação da integridade dos dados, verifica-se que as propriedades dessa soma de verificação não são de todo abrangentes em termos de detecção de erros. A maneira como esse algoritmo de soma de verificação foi escolhido reflete a necessidade de velocidade em combinação com o período (final da década de 1970).

É assim que a soma de verificação TCP é calculada:

Soma de verificação: 16 bits

O campo de soma de verificação é o complemento de 16 bits da soma do complemento de todas as palavras de 16 bits no cabeçalho e no texto. Se um segmento contiver um número ímpar de octetos de cabeçalho e texto a serem somados, o último octeto será preenchido à direita com zeros para formar uma palavra de 16 bits para fins de soma de verificação. O bloco não é transmitido como parte do segmento. Ao calcular a soma de verificação, o próprio campo de soma de verificação é substituído por zeros.

Isso significa que qualquer corrupção que seja equilibrada ao somar os dados dessa maneira não será detectada. Há uma série de categorias de corrupção nos dados que isso permitirá, mas apenas como um exemplo trivial: alterar a ordem das palavras de 16 bits sempre passará despercebido.

Na prática, ele captura muitos erros típicos, mas não garante a integridade. Também é ajudado pelo modo como a camada L2 também faz verificações de integridade (por exemplo, CRC32 de quadros Ethernet), embora apenas para a transmissão no link local, e muitos casos de dados corrompidos nunca são passados para a pilha TCP.

A validação dos dados usando um hash forte, ou preferencialmente uma assinatura criptográfica, é em um nível totalmente diferente em termos de garantia da integridade dos dados. Os dois mal podem ser comparados.

— Håkan Lindqvist
fonte

Melhor resposta! Eu odeio como as outras respostas misturam os conceitos de hashes criptográficos e somas de verificação.

— 0xC0000022L

20

Provavelmente há um zilhão de razões pelas quais se deve verificar o md5sum, mas algumas vêm à minha mente:

Atividade maliciosa - seu ISO pode ter sido adulterado no caminho do servidor
A página em si é falsificada (é melhor ter os md5sums assinados também :))
Download quebrado (apesar da correção de erros do TCP) (verifique isso )
ISO queimado incorretamente

E leva apenas alguns segundos de qualquer maneira.

— Konrad Gajewski
fonte

21

Isso também significa que é razoavelmente seguro baixar um ISO de um site espelho aleatório, desde que você obtenha as somas de verificação de algum lugar confiável; por exemplo, uma postagem assinada por PGP na lista de discussão foo-Announce.

— Richardb

2

Na verdade, nada tem a ver com a proteção contra atividades maliciosas. Se o ISO pudesse ter sido substituído por um malicioso, o valor da soma de verificação MD5 também poderia. Tê-los assinados é uma questão diferente, mas não é sobre o que o OP está perguntando. Portanto, em vez de a "atividade maliciosa" ser a primeira na sua lista (com certeza soa bem), ela na verdade nem deveria estar na sua lista. Você está dando às pessoas uma falsa sensação de segurança, o que é perigoso. superuser.com/questions/849845/...

— Austin '' Danger '' Powers

11

@ Austin''Danger''Powers Umm, não, Konrad está certo. Por um lado, o espelho de download normalmente é diferente do local mostrando a soma de verificação, e em segundo lugar, há um monte de ISPs no mundo que manipulam o tráfego - checksums TCP vai ficar bem, mas você está baixando um arquivo diferente. E, claro, ele está perdendo outro ponto também - o arquivo pode ter sido corrompido no servidor, depois que a soma de verificação foi criada. Isso acontece o tempo todo, especialmente para os servidores mais "amadores" (sem configurações adequadas de RAID etc.).

— Luaan

2

Uma resposta a partir de 2015 deve aconselhar contra hashes MD5 . Esse algoritmo foi quebrado nos últimos dez anos (sem exageros!). Além disso, você está misturando soma de verificação e hash. São duas coisas diferentes com diferentes intenções por trás deles.

— 0xC0000022L

11

Para adicionar ao comentário de @ 0xC0000022L, é melhor evitar o SHA1 se a segurança já for uma grande preocupação também, embora ele e o MD5 sejam perfeitamente adequados para se defender contra corrupção acidental.

— David Spillett

6

O TCP / IP garante a integridade dos dados *. Mas não garante que 100% de um arquivo tenha sido baixado. Pode haver muitas razões pelas quais isso pode acontecer. Por exemplo: É possível que você possa montar uma ISO que perca um ou dois bytes em algum lugar no meio. Você não terá problemas com isso até precisar de um ou dois arquivos específicos que estão corrompidos. A comparação de somas de verificação garante que você realmente baixou o arquivo inteiro.

* ver comentário

— Daniel
fonte

8

Eu acho que "garante a integridade dos dados" está realmente exagerando no que realmente faz. Ele tenta verificar a integridade dos dados com uma abordagem muito enxuta, o que não é particularmente forte.

— Håkan Lindqvist

6

A soma de verificação TCP é de apenas 16 bits. Isso significa que, na ausência de outras somas de verificação, um em cada 65536 pacotes corrompidos será aceito como não corrompido. Se, por exemplo, você estava baixando uma imagem de DVD de 8 GB em um link barulhento com uma taxa de corrupção de 1%, esperaria 81 pacotes corrompidos indetectáveis.

MD5 é uma soma de verificação muito maior, em 128 bits. As chances desses 81 pacotes produzirem algo com a mesma soma de verificação que o original são de cerca de 1 em 1.000.000.000.000.000.000.000.000.000.000.000.000.

— Marca
fonte

6

Há vários motivos para verificar a soma de verificação de um arquivo baixado via HTTP:

Garantindo que você recebeu o arquivo inteiro
- Alguns clientes, como o Firefox , podem tratar uma conexão interrompida como um download bem-sucedido, deixando um arquivo truncado, mas alegando que o download foi feito OK
Garantindo que você recebeu o arquivo correto
- por exemplo, um servidor com erros, comprometido ou mal-intencionado pode enviar a você outra coisa
- alguém pode adulterar a transferência (ataque man-in-the-middle) - até o HTTPS não está seguro se o seu sistema for comprometido por, por exemplo, Superfish, ou se o método de criptografia usado for fraco
- Eles também podem apenas apresentar uma página de download falsa, para que você nem esteja conectado ao servidor real (mas, neste caso, as somas de verificação não ajudarão muito se você as obtiver do mesmo servidor falso)
- Vários ISPs foram flagrados injetando Javascript nas páginas em transmissão por vários motivos ¹ ; dependendo de quão bem isso seja implementado, também poderá alterar alguns downloads de arquivos
- Um espelho pode estar hospedando uma versão desatualizada do arquivo ou o administrador pode ter carregado o arquivo errado
Garantindo que o arquivo não foi corrompido por algo que o TCP não pode detectar
- por exemplo, o arquivo pode estar corrompido no servidor, portanto, o TCP garantirá apenas que o arquivo já corrompido não fique mais mutilado na transmissão
- ou pode ser corrompido depois de chegar ao seu fim, por memória / disco com defeito, driver do sistema de arquivos com erros, etc.
- As somas de verificação TCP são apenas de 16 bits, portanto, as chances não são astronômicas (1 em 65536) de que um pacote corrompido não seja detectado
Com um ISO, garantindo que o disco tenha sido gravado corretamente

¹ fontes no comentário porque lol rep

— Rena
fonte

2

Fontes: * security.stackexchange.com/questions/70970/… * adblockplus.org/forum/viewtopic.php?t=8156 "ISP agressivo injetado / scripts embutidos / anúncios bloqueados" * iamsrijit.wordpress.com/2012/09/ 14 / ... * mais podem ser facilmente encontrados no Google, mas não é realmente sobre o tema aqui

— Rena

2

Daniel, Dependendo da ferramenta que você está usando para o Download ISO, por exemplo. Se for Say Firefox .. Pode mostrar o download do arquivo. No entanto, você pode não ter o ISO completo intacto. Se você o queimar e tentar usá-lo, pode haver informações ausentes. Isso acontece de tempos em tempos em diferentes servidores da web que hospedam arquivos.

É uma boa prática comparar pelo menos o tamanho do arquivo (total de bytes ou bits) para garantir que correspondam. O Windows mostrará a contagem de bytes de arquivo diferente e, em seguida, diga Linux. A verificação de soma MD5 mostrará os mesmos valores, independentemente do sistema operacional usado. Espero que isso ajude um pouco. Felicidades...

— David Thomson
fonte

2

O Windows mostra a contagem de bytes de maneira diferente de como o Linux mostra? Verdade? Eu pensei que o abdômen tivesse saído com o sistema de arquivos do CP / M, tamanho do arquivo como blocos. (Agora, se você estiver visualizando algo diferente da contagem de bytes - por exemplo, a exibição do tamanho do arquivo no Explorer - pode ser bem diferente. Mas nenhum administrador de sistemas sadios deve verificar a integridade do arquivo baixado dessa maneira, portanto, isso não é um questão.) Bytes são bytes. Olhá-lo em termos de bits não faz sentido; quando foi a última vez que você baixou e armazenou meio byte?

— um CVn

2

Percebo muitas respostas interessantes, mas há uma última coisa a considerar: Problema de dois generais

O problema dos dois generais e o problema dos generais bizantinos consideram especificamente as implicações de transferir informações de maneira confiável por canais não confiáveis.

As somas de verificação são apenas mais uma camada de "confiabilidade crescente" e uma com poucas chances de falha. Esta é a razão pela qual é tão popular.

— Fernando Cordeiro
fonte