HTTPS와 VPN은 설치하는 패키지를 인증하지 않는다

업데이트가 실패하면 스레드의 조언은 익숙한 경로를 따른다: 트래픽이 VPN을 지나니 다운로드는 믿을 만할 것이라며, 오류를 넘기려고 서명 검사를 느슨하게 만든다. 서로 다른 두 생각이 한 문장으로 융합된 것이다. 암호화는 두 끝점 사이의 경로를 보호하고, 인증은 그 바이트가 의도한 발행자에게서 왔는지를 결정한다. 터널은 전자를 제공하고 후자에 대해서는 아무 말도 하지 않는다.

증상은 보통 한 호스트, 한 저장소에서 검증 오류가 나고 나머지는 정상적으로 업데이트되는 모습이다. 그 모양은 이미 네트워크 경로가 작동하고 있으며 논쟁의 핵심이 신뢰라는 것을 말해 준다.

서로 다른 질문에 답하는 두 가지 통제

전송 보안은 이 연결의 반대편에 누가 있는지, 경로 위의 누군가가 그것을 읽거나 바꿀 수 있는지를 답한다. 패키지 인증은 이 산출물이 설정한 권위에 의해 게시되었는지를 답하며, 통제하지 않는 미러를 통한 다운로드도 견뎌야 한다.

두 질문이 겹치는 곳은 가장자리뿐이다. 미러의 올바른 인증서는 미러가 미러임을 증명하지만, 미러가 변경되지 않은 발행자 콘텐츠를 담고 있음을 증명하지는 않는다. 서명된 패키지는 발행자가 서명했음을 증명하지만, 네트워크가 최신 버전을 전달했는지 또는 지정한 저장소가 조직이 승인한 곳인지는 알려 주지 않는다.

사람들이 검사를 끄면서 만드는 실패 모드는 성공적인 다운로드 한 번을 위해 두 번째 보장을 영구히 잃는 것이다. 그 거래는 그것이 중요해지는 날까지 보이지 않는다.

apt가 실제로 인증하는 것

APT의 모델은 인증된 아카이브 사슬이다. 서명된 릴리스 메타데이터가 체크섬을 통해 패키지 색인으로 이어지고, 그 색인이 체크섬을 통해 개별 패키지 파일로 이어진다. 사슬을 검증하는 것이 미러를 신뢰할 수 없지만 사용 가능하게 만든다: 미러는 원하는 무엇이든 제공할 수 있고, 메타데이터의 서명이 APT의 수용 여부를 결정한다.

이것은 설치된 모든 패키지에서 유지관리자의 서명을 확인하는 것과 의도적으로 다르며, 그 구분이 버그 보고서에서 «패키지가 서명되었다»와 «아카이브가 인증되었다»가 서로 다른 뜻인데도 뒤바뀌어 쓰이는 이유를 설명한다.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

종료 코드만이 아니라 업데이트 출력을 읽어라. APT는 메타데이터가 실패한 저장소의 이름을 밝히고, 그 이름이 조사할 경계다. 서명 검증 없이 신뢰됨으로 표시된 저장소나 안전하지 않은 저장소에 대한 재정의는 누군가 내린 구성 결정이며 설명할 수 있어야 한다.

최신성은 다시 별개의 속성이다. 유효하게 서명된 메타데이터 파일은 지난주에 본 것보다 오래될 수 있고, 그래서 릴리스 메타데이터에 만료일이 붙으며, 그래서 클라이언트의 시계 문제가 키 문제처럼 보이는 검증 오류를 낳을 수 있다.

dnf5가 따로 확인하는 것

RPM 쪽은 두 개의 서로 다른 스위치를 노출하며, 이를 혼동하면 반대 방향으로 같은 부류의 실수가 생긴다. 하나는 패키지 파일이 유효한 서명을 가져야 하는지를, 다른 하나는 저장소 메타데이터가 서명되어야 하는지를 통제한다. 둘은 독립적으로 설정될 수 있고, 한쪽에 엄격하고 다른 쪽에 관대한 시스템도 가능하다.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

패키지 질의는 설치된 사본의 서명 메타데이터가 어떤 모습인지 보여 주며, 이는 엄격함을 주장하는 구성 파일에 대한 유용한 현실 점검이다. 그것이 말해 주지 않는 것은 배포판이 지원하는 정책이며, 포럼의 일반적인 «GPG를 켜라»는 지시 대신 그것을 따라야 한다.

두 관리자가 다른 곳에서 그 차이는 건축적인 것이지 한쪽이 더 약하다는 신호가 아니다. 둘 다 발행자 콘텐츠를 인증하며, 서명을 사슬의 다른 지점에 둔다.

터널이 더하는 것과 더하지 않는 것

VPN은 필요한 경로를 제공하고, 업데이트 트래픽을 신뢰할 수 없는 접속망 밖에 두고, 지역 관찰자가 보는 것을 줄일 수 있다. 이는 실제 운영상 이점이며, 어느 것도 발행자 인증은 아니다.

HTTPS는 자체 보장을 더하며, 그것은 느껴지는 것보다 좁다. 연결한 TLS 끝점을 인증한다. 그 끝점이 미러라면 미러를 인증한 것이지 그것이 제공하는 아카이브 콘텐츠를 인증한 것이 아니다. 바로 이것이 서명된 메타데이터 사슬이 존재하는 사례다.

어느 통제도 가용성을 약속하지 않는다. 네트워크는 전달을 거부할 수 있고, 인증된 객체가 자동으로 최신은 아니다. 자물쇠 아이콘의 존재로 추론하는 대신 패키지 관리자 자체의 최신성 정책을 사용하라.

실패한 경계를 진단하라

무엇이든 바꾸기 전에 단계를 지목하라: DNS 해석, 프록시나 경로, TLS 끝점의 정체성, 아카이브 인증, 패키지 서명 검사, 또는 설치다. 각각은 고유한 오류 형태와 고유한 소유자를 가진다.

네트워크 경로를 고치는 일에 알 수 없는 서명 키를 신뢰됨으로 선언하거나, 인증서를 무시하거나, 요청하지 않은 저장소 구성을 받아들이는 것이 포함되어서는 안 된다. 키가 실제로 교체되었다면 배포판이나 저장소 소유자가 검증 가능한 경로로 새 키를 게시하며, 그것이 적용해야 할 수정이다.

어느 경계가 실패했고 누가 그것을 소유하는지 적어 두라. 다음 업데이트 실패는 다른 경계에서 일어날 것이고, 목록이 있으면 터널이 업데이트를 안전하게 만드는지에 대한 또 한 번의 논쟁 대신 오 분 진단이 된다.