Os sites que fornecem arquivos ISO para download geralmente fornecem somas de verificação MD5 desses arquivos, que podemos usar para confirmar se o download do arquivo foi feito corretamente e se 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?
Responder1
Como foi observado por outros, existem muitas possibilidades de corrupção de dados onde qualquer soma de verificação na camada de transporte não pode ajudar, como a corrupção que acontece já antes da soma de verificação ser calculada no lado do envio, um MITM interceptando e modificando o fluxo (dados também como somas de verificação), corrupção acontecendo após a validação da soma de verificação no destinatário, etc.
Se desconsiderarmos todas essas outras possibilidades e nos concentrarmos nas especificidades doSoma de verificação TCPem si e o que ele realmente faz em termos de validação da integridade dos dados, verifica-se que as propriedades desta soma de verificação não são de todo abrangentes em termos de detecção de erros. A forma como esse algoritmo de soma de verificação foi escolhido reflete a exigência de velocidade em combinação com o período de tempo (final da década de 1970).
É assim queSoma de verificação TCPé calculado:
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 contém um número ímpar de octetos de cabeçalho e texto a serem verificados, o último octeto é preenchido à direita com zeros para formar uma palavra de 16 bits para fins de soma de verificação. O pad não é transmitido como parte do segmento. Ao calcular a soma de verificação, o próprio campo da soma de verificação é substituído por zeros.
Isso significa que qualquer corrupção que seja equilibrada ao somar os dados dessa forma não será detectada. Há uma série de categorias de corrupção de dados que isso permitirá, mas apenas como um exemplo trivial: a alteração da ordem das palavras de 16 bits sempre passará despercebida.
Na prática, ele detecta muitos erros típicos, mas não *garante* a integridade. Também é ajudado pela forma 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 nem sequer são passados para a pilha TCP.
Validar os dados usando um hash forte, ou de preferência uma assinatura criptográfica, está em um nível totalmente diferente em termos de garantia da integridade dos dados. Os dois mal podem ser comparados.
Responder2
Provavelmente há um zilhão de razões pelas quais alguém deveria 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 interrompido (apesar da correção de erros TCP) (verifiqueessefora)
- ISO gravado incorretamente
E leva apenas alguns segundos de qualquer maneira.
Responder3
O TCP/IP garante a integridade dos dados*. Mas isso não garante que 100% do arquivo tenha sido baixado. Pode haver muitos motivos pelos quais isso pode acontecer. Por exemplo: É possível que você monte um ISO que perca um ou dois bytes em algum lugar no meio. Você não terá problemas com isso até que precise de um ou dois arquivos específicos que estejam corrompidos. A comparação das somas de verificação garante que você realmente baixou o arquivo inteiro.
*ver comentário
Responder4
Existem 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, comoRaposa de fogo, pode tratar uma conexão interrompida como um download bem-sucedido, deixando você com um arquivo truncado, mas alegando que foi baixado corretamente
- Garantindo que você recebeu o arquivo correto
- por exemplo, um servidor com erros, comprometido ou malicioso pode enviar-lhe outra coisa
- alguém pode adulterar a transferência (ataque man-in-the-middle) - mesmo o HTTPS não está protegido contra isso se o seu sistema estiver comprometido, por exemplo, pelo Superfish, ou se o método de criptografia usado for fraco
- Eles também podem 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ê obtê-las do mesmo servidor falso)
- Vários ISPs foram pegos injetando Javascript em páginas em transmissão por vários motivos 1 ; dependendo de quão bem isso for implementado, também poderá prejudicar alguns downloads de arquivos
- Um espelho pode estar hospedando uma versão desatualizada do arquivo ou o administrador pode ter carregado o arquivo errado
- Garantir que o arquivo não foi corrompido por algo que o TCP não consegue detectar
- por exemplo, o arquivo pode estar corrompido no servidor, então o TCP apenas garantirá que o arquivo já corrompido não fique ainda mais danificado na transmissão
- ou pode ser corrompido depois de chegar ao seu lado, por memória/disco defeituoso, driver de sistema de arquivos com bugs, etc.
- As somas de verificação TCP são de apenas 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 foi gravado corretamente
1 fontes no comentário porque lol representante