다운로드 한 파일의 체크섬을 계산하는 이유는 무엇입니까?

19

다운로드 할 수있는 파일 옆에 체크섬이 표시되는 경우가 종종 있습니다. 이 연습의 목적은 저를 피합니다. 분명히 손상된 파일을 감지하는 것이지만 이 손상의 원인은 무엇일까요?

파일은 네트워크 프로토콜에 의해 감지되기 때문에 전송 오류로 인해 파일이 손상되지 않습니다. 또한 악의적 인 목적으로 파일을 변경할 수있는 공격자는 마찬가지로 주어진 체크섬을 변경할 수 있습니다. 하드 드라이브 오류를 확인하고 있습니까? 글을 쓸 때 읽을 때 일어날 가능성이 더 있습니까? 중요한 것이 빠졌습니까?

networking files checksum

— 카롤리스 주 델레
소스

2

또한 악의적 인 목적으로 파일을 변경할 수있는 모든 공격자는 마찬가지로 주어진 체크섬을 변경할 수 있습니다. -합의하면 , 체크섬이 HTTPS를 통해 제공되지 않거나 SSL 인증서가 소프트웨어 작성자에 속하는지 확실 하지 않으면 진위성을 보장하지 않습니다 .

— Mihai

1

TCP 체크섬은 실제로 매우 거칠다. 수천 명의 사람들에게 큰 파일을 제공하는 경우 (설치 DVD 이미지 생각) 이러한 다운로드 중 일부는 감지 할 수 없을 정도로 손상 될 것입니다.

— Mark

@Mihai 물론, 아마도 위험을 약간 줄입니다. 예를 들어 서버가 모든 이진 응답을 자동으로 수정하거나 다운로드 한 모든 실행 파일을 대체하는 바이러스에 감염된 경우입니다. 완벽하지는 않지만 어떤 경우에는 도움이 될 수 있습니다.

— Luaan

9

손상을 감지하는 것은 전적으로 정확하지 않습니다. 소프트웨어의 무결성을 확인하는 것이보다 정확한 사용법입니다. 일반적으로 소프트웨어는 단일 서버에서 배포되지 않습니다. 여러 서버에서 동일한 소프트웨어가 배포 될 수 있습니다. 따라서 특정 소프트웨어를 다운로드 할 때 다운로드 속도를 높이기 위해 대상과 가장 가까운 서버가 다운로드 소스로 선택됩니다. 그러나 이러한 '비공식'(타사) 서버를 항상 신뢰할 수있는 것은 아닙니다. 그들은 / 포함 할 수 있습니다 트로이 목마 / 바이러스 / 애드웨어 / 인 프로그램에 백도어 좋지 않다 .

따라서 다운로드 한 소프트웨어가 관련 조직에서 출시 한 '공식'소프트웨어와 정확히 동일하도록 체크섬이 사용됩니다. 체크섬을 생성하는 데 사용되는 알고리즘은 프로그램을 약간만 변경해도 완전히 다른 체크섬이됩니다.

Practical Unix 및 인터넷 보안 에서 가져온 예

MD5 (파란색 상자에 $ 1500가 있습니다.) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (파란색 상자에 $ 1100가 있습니다.) = d6dee11aae89661a45eb9d21e30d34cb

단일 문자 (및 문자 내에서 단일 이진 비트 만)가 다른 메시지는 완전히 다른 메시지 다이제스트를 갖습니다.

다운로드 한 파일에 '공식'웹 사이트에 제공된 체크섬과 동일한 체크섬이 있으면 소프트웨어를 수정하지 않은 것으로 가정 할 수 있습니다.

참고 : 이론적으로 두 개의 서로 다른 파일은 동일한 해시 값을 가질 수 있습니다. 해시 / 체크섬 알고리즘이 안전한 것으로 간주 되려면 동일한 체크섬을 생성하는 다른 파일을 찾는 것이 계산적으로 매우 비싸야합니다.

— 아스 윈 PJ
소스

1

따라서 파일과 체크섬이 동일한 호스트에서 제공되면 다소 쓸모가 없습니까?

— Karolis Juodelė

아마도. 체크섬은 무결성을 확인하는 수단 일뿐입니다. 특정 시나리오에서 공격자가 조직의 FTP 서버에 액세스하면 소프트웨어를 변경할 수 있습니다. 그러나 여전히 동일한 체크섬을 사용하여 공격자가 HTTP 서버에 침입하지 않은 경우 무결성을 확인하는 것만 가능합니다. 따라서 둘 다 공격자의 통제를 받으면 쉽게 변경할 수 있으며 차이점을 알 수 없습니다.

— Aswin PJ

1

체크섬이 관련 될 수있는 또 다른 상황은 딸꾹질 후에 파일 전송이 재개되지만 그 중간에 파일이 변경된 상황을 감지하는 것입니다.

— supercat

@ KarolisJuodelė 다운로드 링크는 같은 웹 사이트 / 호스트에있을 수 있습니다. 그러나 어떤 서버가 가장 가까운 지에 따라 해결되는 위치가 다를 수 있습니다. 또한 체크섬 페이지는 https이어야하며 다운로드는 http 또는 ftp 프로토콜 일 수 있습니다.

— balki

10

또한 악의적 인 목적으로 파일을 변경할 수있는 모든 공격자는 마찬가지로 주어진 체크섬을 변경할 수 있습니다.

항상 그런 것은 아닙니다.

HTTPS에서 제공되는 체크섬과 함께 컨텐츠 링크를 가질 수 있습니다. 링크는 암호화되지 않은 링크 (일반 HTTP 또는 FTP 등) 일 수 있습니다.

단점은 암호화되지 않은 연결이 쉽게 중간에 도달 할 수 있으며, 거꾸로 웹 마스터에게는 더 빠르고 편리 할 수 있습니다 (컴퓨팅 리소스가 적고 네트워크가 해당 항목을 캐시 할 수있는 기회).

체크섬이 끊어지지 않은 신뢰할 수있는 연결로 제공되고 페이로드가 체크섬과 일치하면 두 가지 이점을 모두 얻을 수 있습니다 (체크섬이 암호로 안전한 경우).

즉, "안전"하다고 주장하는 배포판이 있지만 이미지에 대한 링크와 마찬가지로 웹 사이트가 HTTP에만 있음을 상기시켜주었습니다.

예 :

더 안전하지 않을 수 없기 때문에 재미 있습니다. 악의적 인 사용자가 아니더라도 모든 ISP는 웹 사이트와 이미지를 모두 가짜로 쉽게 대체 할 수 있으며 누군가가 "안전한"Linux 배포판을 얻는 것처럼 조작 된 운영 체제를 설치하도록 할 수 있습니다. pwnage.

— PSkocik
소스

1

인증되지 않은 HTTP보다 보안 성이 떨어지는 많은 것들이 있습니다. 이로 인해 MIMI가 파괴되어야합니다.

— user253751

4

TCP / IP 오류 검사가 모든 것을 포착하지 못하는 이유 : https : //.com/a/17083365/2551539

[Jacob Krall이 지적한] TCP가 감지 할 수있는 다른 오류가 있습니다 .

패킷 순서가 잘못됨
패킷 손실
패킷 내부의 손상된 데이터
팬텀 패킷 (수신기는 보내지 않은 패킷을받습니다)

몇 가지 추가 정보로 편집하십시오.

이 연구의 9 페이지 : http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf 는 TCP에 의해 감지되지 않을 수있는 오류가 있음을 제안합니다. 내 이해는 잘못된 데이터 그램 (연구에서 "나쁜 쌍둥이"라고 함)이 의도 한 데이터 그램 (연구에서 "좋은 쌍둥이"라고 함)과 동일한 체크섬을 가질 때 발생한다는 것입니다.

— 제시 아담
소스

2

그 대답을보다 신중하게 읽으십시오-TCP로 수정 된 모든 오류입니다.

— Jacob Krall

4

전송 오류가 발생할 수 있습니다. 링크 계층 프로토콜에는 일반적으로 체크섬 또는 오류 수정 코드가 포함되어 있으므로이를 피할 수는 있지만 완벽하지는 않습니다. 오류가 수정되지 않을 가능성은 적습니다. TCP 패킷에는 체크섬이 포함되어있어 오류 가능성을 2 ^ 16만큼 줄입니다. 전송 오류의 가능성은 매우 작지만 0이 아닙니다. 그것은 대부분의 사람들이 자신도 모르게 평생 만날 수없는 일이지만, 수십억 년 전의 암호 체크섬 가능성 범위는 아닙니다.

캐시 된 복사본에서 체크섬이 계산되므로 다운로드 후 바로 확인하면 디스크 손상과 같은 클라이언트의 하드웨어 오류가 감지되지 않을 수 있습니다. 부트 매체가 부트에 실패한 경우 손상되지 않았는지 점검하는 것이 유용합니다. 반면에 매체를 실제로 테스트하고 있으며 하드웨어에 문제가있을 수 있다는 전제가 있습니다.

체크섬을 계산하는 실제 이유는 실제로 소프트웨어 수준 오류를 감지하기 때문입니다. 이런 일이 발생합니다. 가능한 오류는 다음과 같습니다.

파일이 부분적으로 다운로드되었습니다. 웹 서버와 브라우저는 중단 된 연결을 감지하고 부분 파일을 정리하는 데 좋지 않은 경향이 있습니다. 다운로드 중 오류가 발생했거나 업로드 중 오류가 발생했을 수 있습니다.
도중에 약간의 부패가있었습니다. 예를 들어, 파일 배포의 일부 중간 노드는 이진 파일에 텍스트 인코딩 변환을 적용하기로 결정했습니다. 또는 잘못 구성된 일부 서버가 내용 대신 오류 메시지를 표시했습니다.
변형 : 잘못된 파일이 업로드되었습니다.
드물지만 보호 할 수 있습니다. 공격자가 파일을 변경했지만 참조 체크섬을 변경할 수 없었습니다. 보안 인프라는 공격자가 잘못된 파일보다 잘못된 체크섬을 전파하기 어렵게 만드는 경향이 있습니다. 예를 들어, 큰 파일은 종종 미러를 통해 배포되는 반면 체크섬은 변조 가능성이 적은 중앙 사이트에서 제공됩니다 (프로젝트 리더에게만 서버 액세스, HTTPS를 통한 배포).

실제로 다운로드 한 파일의 크기를 확인하면 잘려 지거나 잘못 변환 된 파일 인 가장 일반적인 오류가 발생합니다. 체크섬은 더 많은 문제를 엄격하게 감지한다는 이점이 있습니다.

— 질 'SO- 악마 그만해'
소스

2

이론적으로 네트워크는 모든 단일 세그먼트를 올바르게 전달하고 디스크에 올바르게 조립되며 아무 문제가 없습니다.

실제로 컴퓨터는 기계와 소프트웨어이며 둘 다 오류가있는 사람에 의해 설계되고 만들어졌습니다. 무해하거나 악의적이든 데이터를 엉망으로 만드는 중개 장치를 통한 다운로드와 같이 어떤 식 으로든 다운로드가 어떤 이유로 든 제대로 수행되지 않는 경우 파일이 거의 확실하게 파일인지 확인하는 것이 좋습니다 공급자 측에서 파일의 정확한 복제본으로 다운로드됩니다.

고품질 체크섬은 데이터 무결성을 검증하는 신뢰할 수있는 방법입니다.

— 제이슨
소스

0

많은 파일이 동일한 체크섬에 매핑되므로 체크섬을 100 % 신뢰할 수 없습니다.

우리는 때 추가 기차 우리에게 또 다른 검사를 곱하면 에러를 검출 확률.

인터넷에는 트래픽이 너무 많아 오류가 실제로 일반적입니다.

— 영국에서 쫓아
소스

비트 부패도 있습니다.

— 사슴 사냥꾼

스토리지 하드웨어 자체에서 감지해야하지만 ZFS 및 btrfs의 주요 기능인 체크섬은 완벽하게 작동하는지 의심합니다.

— Max Ried

0

체크섬은 또한 다음과 같은 상황으로 인해 손상된 다운로드를 방지하는 데 도움이됩니다.

다운로드를 제공하는 동안 서버에 내부 오류가 발생하여 다운로드가 종료되었습니다.

그런 경우 몇 가지 가능한 결과가 있습니다.

좋은 서버 -서버의 청크 전송 인코딩 구현은 버그 가 없습니다 .
- cURL, wget과 같은 양호한 클라이언트 는 종료 청크가 서버에서 전송 된 적이 없기 때문에 이것이 잘못된 다운로드임을 알릴 수 있습니다.
- 불량 클라이언트 는 서버에서 더 이상 데이터를 수신하지 않으므로 다운로드가 완료된 것으로 생각합니다.
잘못된 서버 -서버의 청크 전송 인코딩 구현 은 버그 로 인해이 잘못된 다운로드에 대해 종료 청크를 보냅니다.
- 모든 클라이언트 는이 다운로드가 성공적으로 완료된 것으로 생각합니다.

나는 인기있는 클라이언트 도구와 서버 프레임 워크에서 이러한 동작을 보았으므로 체크섬을 사용하지 않으면 "좋은 서버 + 나쁜 클라이언트"또는 "나쁜 서버 + 모든 클라이언트"의 경우 손상된 다운로드가 눈에 띄지 않습니다. .