
apt
에서 패키지를 설치할 때 때때로 다음과 같은 작업을 수행하는 것으로 나타났습니다 .
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
내가 올바르게 이해했다면 여기서 우리가 하는 일은 에서 GPG 공개 키를 가져와서 https://download.../gpg
에 넣는 것입니다 /usr/share/keyrings/docker-archive-keyring.gpg
. 그런 다음 apt에 "패키지를 다운로드할 때 https://download.docker.com/...
이 패키지가 이 공개 키에 속한 개인 키로 서명되었는지 확인하세요"라고 지시합니다.
그래서 저는 잘 이해가 되지 않습니다. 반대편에 있는 Docker가 Docker라고 믿고 https://download.docker.com/..
여기에서 공개 키를 가져오기 때문에 신뢰한다면 왜 GPG 키를 사용하여 거기에서 오는 패키지를 확인해야 합니까? ?
나에게는 자체 서명된 인증서처럼 들립니다.
여기서 뭔가 빠졌나요?
답변1
이는 여러 가지 이유가 있으며 모두 다음을 중심으로 진행됩니다.중간자 공격(MITM) - 구체적으로, 미래에 MITM 공격이나 '거짓 다운로드 소스'로의 다른 종류의 악의적인 리디렉션을 당하는 경우로부터 사용자를 보호합니다.~ 후에좋은 열쇠를 얻었군요.
최악의 상황에 처한 경우(시스템이 이미 손상되어 악의적인 행위자가 있는 나쁜 사이트(줄여서 "MA")로 리디렉션됨)에 처하게 되면 당황하게 되고 이것이 당신을 보호하지 못합니다. MA의 키를 다운로드할 예정입니다. 여기서 PGP 키와 키링을 보호하는 것은 이것이 아니라 다음과 같은 위험으로부터 사용자를 보호하는 것입니다.미래MITM 공격.
이 예에서는 이미 손상되었으며 MA가 이 시점에서 컴퓨터, 네트워크, 데이터 등을 제어할 가능성이 높기 때문에 사용 중인 키는 중요하지 않습니다. 그러나 가장 일반적인 보호 시나리오는시작깨끗한 환경/시스템과그 다음에합법적인 소스에서 소프트웨어를 설치합니다. (다음 섹션 참조)
그러나 손상된 환경에서 시작하는 것은 여기서 주요 서명이 보호하는 '일반적인 시나리오'가 아닙니다. 가장 일반적인 시나리오는 다음과 같습니다. 깨끗한 시스템, 깨끗한 업데이트, 시스템 손상 없음, 사용하는 DNS 서버, 연결된 네트워크 등이 있습니다.
Docker를 설치하고 실제 Docker 웹사이트에서 Docker 키를 가져옵니다. 그런 다음 Docker를 설치하면 키의 유효성이 검사됩니다.
미래의 어느 시점에서 MA는 귀하의 트래픽이 인터넷으로 흐르는 방식을 제어하고 귀하를 '가짜' Docker 다운로드 사이트로 리디렉션했습니다.
MA가 해당 개인 키를 사용하여 Docker에서 PGP 키를 훔치지 않는 한 apt
시스템은 다음과 같은 서명을 표시합니다.download.docker.com
일치하지 않는그리고 귀하의 환경에서 이상한 일이 일어나고 있으며 MA의 '나쁜' 저장소 리디렉션의 업데이트를 적용하지 않을 것입니다.
이것키 서명과 주요 부분이 보호하는 것은 다음과 같습니다.미래. 귀하가 이미 침해된 경우에는 귀하를 보호하지 않으며 아무것도 보호하지 못할 것입니다. 처음에는 깨끗하고 타협하지 않고 시작하면 보호해 줍니다.~이 되다어떤 이유로 손상되었습니다.
이는 알려진 양호한 키 지문과 비교하여 키 지문을 확인해야 하는 이유이기도 합니다. 대부분의 우수한 리포지토리 제공업체는 수동으로 검증할 수 있는 지문을 쉽게 제공하므로 키를 가져오고 신뢰하기 위해 JUST 명령에 의존하지 않아도 됩니다.