다운로드용 ISO 파일을 제공하는 웹사이트에서는 해당 파일의 md5 체크섬을 제공하는 경우가 많습니다. 이를 통해 파일이 올바르게 다운로드되었고 손상되지 않았는지 확인하는 데 사용할 수 있습니다.
이것이 왜 필요한가요? 확실히 TCP의 오류 수정 속성이면 충분합니다. 패킷이 올바르게 수신되지 않으면 재전송됩니다. TCP/IP 연결의 특성 자체가 데이터 무결성을 보장하지 않습니까?
답변1
다른 사람들이 지적했듯이 전송 계층의 체크섬이 도움이 될 수 없는 데이터 손상 가능성이 많습니다. 예를 들어 전송 측에서 체크섬이 계산되기 전에 이미 손상이 발생하거나 MITM이 스트림을 가로채서 수정합니다(데이터도 마찬가지). 체크섬), 수신 측에서 체크섬을 확인한 후 손상이 발생하는 등
만약 우리가 다른 모든 가능성을 무시하고 다음의 구체적인 사항에만 초점을 맞춘다면TCP 체크섬데이터 무결성 검증 측면에서 실제로 수행하는 작업과 관련하여 이 체크섬의 속성은 오류 감지 측면에서 전혀 포괄적이지 않은 것으로 나타났습니다. 이 체크섬 알고리즘이 선택된 방식은 오히려 기간(1970년대 후반)과 결합된 속도 요구 사항을 반영합니다.
이 방법은TCP 체크섬계산됩니다:
체크섬: 16비트
체크섬 필드는 헤더와 텍스트에 있는 모든 16비트 단어의 1의 보수 합계에 대한 16비트 1의 보수입니다. 세그먼트에 체크섬을 적용할 홀수 개의 헤더 및 텍스트 옥텟이 포함되어 있는 경우 마지막 옥텟의 오른쪽이 0으로 채워져 체크섬 목적으로 16비트 워드를 형성합니다. 패드는 세그먼트의 일부로 전송되지 않습니다. 체크섬을 계산하는 동안 체크섬 필드 자체는 0으로 대체됩니다.
이는 이러한 방식으로 데이터를 합산할 때 균형을 이루는 모든 손상이 감지되지 않음을 의미합니다. 이를 통해 허용되는 데이터 손상 범주에는 여러 가지가 있지만 간단한 예를 들면 다음과 같습니다. 16비트 단어의 순서를 변경하면 항상 감지되지 않습니다.
실제로는 많은 일반적인 오류를 포착하지만 무결성을 전혀 *보장*하지는 않습니다. 또한 L2 계층이 무결성 검사(예: 이더넷 프레임의 CRC32)를 수행하는 방법도 도움이 됩니다. 비록 로컬 링크에서의 전송에만 해당되고 손상된 데이터의 많은 경우는 TCP 스택으로 전달되지도 않습니다.
강력한 해시 또는 바람직하게는 암호화 서명을 사용하여 데이터를 검증하는 것은 데이터 무결성 보장 측면에서 완전히 다른 수준입니다. 둘은 거의 비교할 수도 없습니다.
답변2
md5sum을 확인해야 하는 이유는 셀 수 없이 많지만 내 마음에는 몇 가지가 떠오릅니다.
- 악의적인 활동 - 서버에서 전송되는 도중에 ISO가 변조되었을 수 있습니다.
- 페이지 자체가 스푸핑되었습니다(md5sum도 서명하는 것이 가장 좋습니다 :))
- 손상된 다운로드(TCP 오류 수정에도 불구하고)(확인이것밖으로)
- ISO가 잘못 연소됨
어쨌든 몇 초 밖에 걸리지 않습니다.
답변3
TCP/IP는 데이터 무결성을 보장합니다*. 하지만 파일이 100% 다운로드되었다는 보장은 없습니다. 이런 일이 발생할 수 있는 이유는 여러 가지가 있을 수 있습니다. 예: 중간 어딘가에 1~2바이트가 누락된 ISO를 마운트할 수 있습니다. 손상된 하나 또는 두 개의 특정 파일이 필요할 때까지 문제가 발생하지 않습니다. 체크섬을 비교하면 실제로 전체 파일을 다운로드했는지 확인할 수 있습니다.
*댓글 참조
답변4
HTTP를 통해 다운로드된 파일의 체크섬을 확인하는 데는 여러 가지 이유가 있습니다.
- 전체 파일을 받았는지 확인
- 다음과 같은 일부 클라이언트파이어폭스, 중단된 연결을 성공적인 다운로드로 처리하여 파일이 잘린 상태로 남지만 성공적으로 다운로드되었다고 주장할 수 있습니다.
- 올바른 파일을 받았는지 확인
- 예를 들어 버그가 있거나 손상되었거나 악의적인 서버가 다른 것을 보낼 수 있습니다.
- 누군가가 전송을 조작할 수 있습니다(중간자 공격). 시스템이 예를 들어 Superfish에 의해 손상되었거나 사용 중인 암호화 방법이 약한 경우 HTTPS도 안전하지 않습니다.
- 또한 잘못된 다운로드 페이지를 표시할 수도 있으므로 실제 서버에 연결되어 있지도 않습니다(그러나 이 경우 동일한 가짜 서버에서 체크섬을 가져오면 체크섬이 별로 도움이 되지 않습니다).
- 여러 가지 이유로 전송 중인 페이지에 Javascript를 삽입하는 ISP가 적발되었습니다 1 ; 이것이 얼마나 잘 구현되었는지에 따라 일부 파일 다운로드도 엉망이 될 수 있습니다.
- 미러가 오래된 버전의 파일을 호스팅하고 있거나 관리자가 잘못된 파일을 업로드했을 수 있습니다.
- TCP가 감지할 수 없는 것에 의해 파일이 손상되지 않았는지 확인
- 예를 들어 파일이 서버에서 손상될 수 있으므로 TCP는 이미 손상된 파일이 전송 중에 더 이상 손상되지 않았는지 확인합니다.
- 또는 메모리/디스크 결함, 파일 시스템 드라이버 버그 등으로 인해 도착 후 손상될 수 있습니다.
- TCP 체크섬은 16비트에 불과하므로 손상된 패킷이 감지되지 않을 가능성은 천문학적이지 않습니다(65536 중 1).
- ISO를 사용하면 디스크가 올바르게 구워졌는지 확인합니다.
ㅋㅋㅋ 담당자라서 댓글에 소스 1개 있음