리포지토리 목록은 안전합니까? HTTPS 버전이 있습니까?


24

저장소 업데이트는 안전합니까?

개발자 측의 작은 두뇌로서 저장소 목록이 왜 http://security.ubuntu.com그리고 http(보안되지 않은) 사이트에 나열되어 있는지 이해할 수 없습니다 /etc/apt/sources.list. 인증서 체인 일치가 없으면 "ubuntu.com 사이트 요청 ..."대신 "업데이트 할 패키지 목록에 대한 응답자 요청"으로 나타납니다.

모든 네트워크가 업데이트 사이트를 스푸핑하도록 선택할 수 있습니까? 이것이 로컬 캐시되고 검증 된 사본을 제공하는 일반적인 방법입니까?

답변:


30

간단히 말해, 파일 서명에 사용되는 공개 키 암호화로 인해 안전합니다.

APT에서 다운로드 한 모든 파일에는 서명이있어 컴퓨터에 저장된 공개 키와 Ubuntu 만 있고 Ubuntu 만 서명하여 다운로드 한 파일을 확인할 수 있습니다. 이것은 당신이받은 파일이 어떤 단계에서 Ubuntu에 의해 승인되었고 그 이후로 수정되거나 변조되지 않았 음을 확인합니다.

이것이 어떻게 작동하는지에 대한 기술적 인 설명은 우분투 와 같은 시스템을 사용하는 데비안에서 얻을 수 있습니다 .

예, 도청자가 HTTPS 대신 HTTP를 사용하기 때문에 다운로드중인 파일을 볼 수 있지만이 경우 프라이버시는 걱정할 필요가 없습니다. 유해한 코드를 주입하기 위해 패키지를 수정하려는 중간자 시도는 서명 메커니즘을 손상시키기 때문에 여전히 실패합니다.

이 서명 메커니즘의 한 가지 가능한 문제점은 패키지의 최신 버전을 얻는다는 보장이 없다는 것입니다 (실제로 미러 업데이트 속도가 느림). 이 문제를 완화하기 위해 서명 된 릴리스 파일에는 "유효한 날짜"날짜가 포함되며이 날짜 이후에는 참조하는 모든 파일이 오래된 것으로 간주됩니다. 중간 사용자가이 유효 기간까지 수정되지 않은 이전 버전의 아카이브로 아카이브를 대체하고 APT가 업데이트가 없다고 생각하게하는 것은 그럴듯합니다. 그러나 패키지를 임의로 수정하거나 특정 시점을지나 시간을 거슬러 갈 수는 없습니다.

서명 메커니즘은 파일이 Ubuntu에 의해 제어되지 않는 많은 서버에서 미러링되는 이러한 종류의 분산 환경에서 HTTPS보다 훨씬 우수한 보안을 제공합니다. 본질적으로 미러가 아닌 Ubuntu 만 신뢰하면되므로 파일이 원래 Ubuntu에서 왔으며 그 이후로 수정되지 않았 음을 증명해야합니다. 미러의 ID를 확인할 필요가 없습니다.

PPA와 같은 비공식 저장소를 소스 목록에 추가하면 Ubuntu에서 서명하지 않은 파일을 수신하게됩니다. APT는 Ubuntu가 승인 한 컴퓨터에 설치된 공개 키와 일치하는 인증서로 서명하지 않았으므로 이에 대해 경고해야합니다.


1
큰! 따라서 짧은 버전은 "전송 계층은 안전하지 않지만 각 패키지는 서명되어 있습니다. 사용 가능한 업데이트의 보안 목록이 없으며 기존 보안 문제에 대한 패치가 제공되지 않을 수 있습니다."
찰스 메리 엄

2
"사용 가능한 업데이트의 보안 목록이 없습니다"라는 의미를 모르지만 릴리스 파일 및 패키지 목록 서명하십시오. 미러가 최신인지 확인하지 않습니다.
thomasrutter

3
Er, 미러 또는 기본 사이트가 최신인지 확인할 방법이 없으면 사용 가능한 업데이트, 보안 업데이트 또는 기타 방법이 있는지 알 수있는 방법이 없습니다. 즉, 사용 가능한 업데이트의 보안 목록이 없습니다.
Charles Merriam

4
Alice는 Ubuntu를 실행합니다. Bob은 Alice의 인터넷 연결을 제어합니다. Bob은 각 패키지가 서명되었으므로 Alice의 설치에 잘못된 패키지를 넣을 수 없습니다. 우분투에는 거대한 보안 결함이 있습니다. Alice는 업데이트 된 패키지를 찾으려고하지만 Bob은 Alice의 업데이트 확인에서 패키지에 대한 모든 언급을 제거합니다. Alice는 sysadmin을 해킹 한 후 ubuntu.com에서 HTTPS를 통해 업데이트 확인을 가져와 보안 링크를 따라 실제 웹 사이트에 연결되어 있는지 확인합니다. 이제 Alice는 보안 업데이트를보고 Bob은 숨길 수 없습니다.
찰스 메리 엄

3
이것은 물론 정답입니다. 그러나 내가 이상하게 생각하는 것은 아무도 업데이트 한 패키지와 업데이트하지 않은 패키지를 포함하여 설치된 모든 패키지 목록을 순서대로 컴파일하는 도청자가 걱정되는 것으로 보이지 않는다는 것입니다. 해당 패키지의 보안 취약점.
Teekin

8

여기서 가장 높은 등급의 답변은 구식입니다. 그 이후로 버그가 많은 패키지 확인으로 인해 apt에서 2 개의 심각한 원격 코드 실행 익스플로잇이 발견되었습니다. 여기여기에 보안 게시판이 있습니다 .

이것은 프라이버시 / 정보 유출 및 오래된 패키지 버전에 대한 우려보다 훨씬 나쁩니다. 이것은 임의의 코드 실행을 루트의 완전한 보안 실패로 가능하게합니다. 그리고 문제는 다음과 같습니다. http 대신 https를 사용하면 이러한 공격을 막을 수 있습니다.

이것은 심층 방어 원칙이 다른 어느 곳에서도 적용 된다는 것을 증명합니다 . https를 중심으로 떠 다니는 많은 주장은 이러한 악용에서 알 수 있듯이 apt의 맥락에서 보안상의 이점이 없거나 최소한의 이점을 제공하는 것은 간단하지 않습니다.

문제는 https의 보안 이점이 캐싱, 오버 헤드 증가 등의 측면에서 비용 가치가 있는지 여부입니다. 나는 대답 할 수 없지만 최소한 Ubuntu / Canonical / Launchpad는 저장소에 선택적 https 끝점을 제공해야한다고 생각합니다. .


1
보안은 또한 개인 정보 보호에 관한 것이며 HTTPS는 최소한 어떤 패키지 및 버전을 실행하고 있는지 파악하는 데 훨씬 더 어려운 시간을 의미합니다.
l0b0

apt 자체가 이것에 문제가없는 한 http는 괜찮습니다. 그러나 https는 gpg 보안 (또는보다 정확하게 사용하는 방법)이 엉망인 경우 백업을 제공합니다.
RoundDuckMan

2

중요한 보충 : 사실, 업그레이드 및 초기 설치가 온라인으로 다운로드됨에 따라 많은 트래픽이 소요되며 이러한 트래픽의 소스, 즉 이진 및 텍스트 코드 스트림을 재현 할 수 있습니다. 따라서 인터넷에는 수많은 게이트웨이와 캐시 장치가 있습니다. 내보내기 대역폭을 절약하기 위해 많은 수의 ISP가 http 프로토콜을 기반으로 캐시를 설정했으며 https 프로토콜은 투명한 캐시로 존재할 수 없습니다.

또 다른 이유는 http 기반 미러링 프로그램이 훨씬 단순하고 tls-ssl 인증서를 확인할 필요가 없으며 인증서 무효화 또는 웹 서버 구성 문제에 대해 걱정할 필요가 없기 때문입니다.

얼마 전, 인터넷이 시작될 때 약 20 년 동안 https와 인터넷 트래픽은 여전히 ​​매우 비싼 게임이었습니다. 따라서 http에는 온라인으로 소프트웨어 패키지 배포를위한 설치 및 업데이트를 제공하는 주요 방법으로 사용되지 않는 ftp 프로토콜도 포함되었습니다.

마찬가지로, Microsoft Windows 및 Office도 http를 사용하여 업그레이드됩니다. 일반적으로 Microsoft 서버에서 다운로드 한 설치 패키지가 아니라 ISP의 자체 빌드 캐시 서버임을 알 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.