debian apt 도구에 대한 https 전송이없는 이유는 무엇입니까?

있습니다. apt-transport-https 패키지를 설치해야합니다. 그런 다음 sources.list 파일에서

 deb https://some.server.com/debian stable main 

와 같은 줄을 사용할 수 있습니다. 그러나 일반적으로 전체 콘텐츠가 공개되고 암호화 오버 헤드와 대기 시간이 추가되기 때문에 일반적으로 필요하지 않습니다. 공격자의 공개 키를 신뢰하지 않기 때문에 http 트래픽도 MitM 공격으로부터 안전합니다. apt는 공격자가 조작 된 패키지를 삽입 할 때 경고하고 패키지를 설치하지 못합니다.

편집 : 주석에서 언급했듯이 실제로 사용하는 것이 더 안전합니다. TLS 저장소. 연구에 따르면 암호화되지 않은 저장소에서 apt를 사용하면 HTTP 전송이 재생 공격에 취약하기 때문에 실제로 보안 위험이 발생할 수 있습니다.

댓글 h3>

• 아니요, 대부분의 미러는 https를 지원하지 않습니다. 단순히 이러한 종류의 트래픽을 암호화하는 것이 ‘별로 의미가 없기 때문입니다. 어쨌든 패키지는 확인 중이며 정보는 공개됩니다.
• TLS를 통해 다운로드하는 것을 선호 할 수있는 몇 가지 이유를 생각할 수 있습니다. 1) 패키지를 설치할 때 내 개인 정보가 중요 할 수 있습니다. 2) 거기 MITM이 악용 할 수있는 패키지 서명 검사 코드의 버그 일 수 있습니다.
• @JackO ‘ Connor, 개인 정보에 대한 첫 번째 이의는 이해할 수 있지만 두 번째는 TLS 코드에 버그가있을 수 있기 때문에 PGP 키로 콘텐츠에 서명하는 웹 사이트를 좋아한다고 말하는 것과 같습니다. PGP와 TLS는 모두 신뢰를 구축합니다. ‘ 둘 다 필요하지는 않습니다.
• @Marco 귀하의 답변이 잘못되었습니다. 수많은 연구 논문에서 APT 및 YUM 저장소 모두 GPG 서명을 사용하더라도 HTTP를 통해 저장소에 액세스 할 때 재생 공격에 취약한 것으로 나타났습니다. 저장소는 100 % TLS를 통해서만 액세스해야합니다.
• 여기 는 @Joe Damato가 언급 한 논문입니다. 답변 여기

가정이 잘못되었습니다. HTTPS 다운로드를 사용할 수 있습니다. 이를 지원하는 미러를 찾아서 소스 목록에 해당 URL을 입력하면됩니다. “ apt-transport-https 패키지를 설치해야합니다.

Debian은 HTTPS를 만들지 않습니다. 이점이 거의 없기 때문에 쉽게 다운로드 할 수 있습니다. Debian 패키지 배포에는 이미 패키지를 확인하는 메커니즘이 포함되어 있습니다. 모든 패키지는 Gpg 로 서명됩니다. 활성 man-in-the-middle이 트래픽을 손상된 패키지가있는 서버로 리디렉션하면 GPG 서명이 유효하지 않기 때문에 손상이 감지됩니다. HTTPS 대신 GPG를 사용하면 더 많은 위협으로부터 보호 할 수있는 이점이 있습니다. 최종 사용자 연결에서 활성 중간자 (man-in-the-middle)뿐만 아니라 불량하거나 감염된 미러 또는 패키지 배포 체인의 다른 문제에 대해서도 대응합니다.

HTTPS는 약간의 개인 정보 보호 이점을 제공합니다. 다운로드하는 패키지를 모호하게하지만 수동적 인 관찰자는 여전히 컴퓨터와 패키지 서버 간의 트래픽을 감지 할 수 있으므로 사용자가 데비안 패키지를 다운로드하고 있음을 알 수 있습니다. 또한 파일 크기에서 어떤 패키지를 다운로드하는지 알 수 있습니다.

HTTPS가 도움이되는 곳은 알려진 유효한 설치 이미지를 얻기 위해 신뢰를 부트 스트랩하는 것입니다. Debian은 그렇지 않습니다. ” 설치 미디어 의 체크섬이 있지만 HTTP를 통해서만 제공되는 것 같습니다.

설명

• 설치 미디어의 HTTPS 버전이 있습니다. cdimage.debian.org/debian -cd
• 효과가 거의 없습니까? justi.cz/security/2019/01/22/apt-rce.html 은 어떻습니까?
• @AaronFranke HTTPS보다 HTTP로 악용하기가 더 쉽다는 것은 거의 이점이 없습니다. HTTP가 HTTPS보다 공격 표면이 더 큰 것처럼 ‘는 아닙니다. 실제로 HTTPS 자체에는 더 많은 코드가 포함되기 때문에 더 큰 공격 표면이 있습니다. 따라서 ‘ 순이익도 전혀 없습니다. ‘ 두 가지 한계 위험 간의 상충 관계입니다.

최근에 회사의 적절한 저장소 문제를 발견했습니다. 문제는 표준 http를 사용하는 경우 다른 사람이 쉽게 패키지를 얻을 수 있습니다. 회사는 자체 독점 소프트웨어를 패키징하고 모든 사람과 공유하고 싶지 않기 때문에 http 전송이 문제가됩니다. 비극이 아니라 문제입니다. 패키지에 대한 액세스를 제한하는 방법에는 몇 가지가 있습니다. -방화벽, 웹 서버 수준에서 액세스 제한, ssh를 전송으로 사용.이 주제에 대한 읽기가 매우 쉽습니다. 개인 Debian 저장소에 대한 액세스 제한

이 경우에는 https 전송 + 클라이언트 인증서 인증을 사용하기로 결정했습니다. 간단히 말하면 다음과 같은 작업이 수행됩니다.

1. 자체 서명 된 인증서, 클라이언트 및 서버 (easy-rsa 사용);

2. https 만 허용하도록 리포지토리 앞에 웹 서버를 구성합니다. nginx의 경우 다음과 같이 보일 수 있습니다.

   server { listen 443; root /path/to/public; server_name secure_repo; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:; ssl_prefer_server_ciphers on; ssl_client_certificate /etc/nginx/ssl/ca.crt; ssl_verify_client on; location / { autoindex on; } } 

3. 클라이언트 인증서, 클라이언트 키 및 CA 인증서를 / etc / apt /에 넣습니다. ssl 및 Ubuntu의 경우 00https 파일을 /etc/apt/apt.conf.d에 추가합니다.

   Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

자체 서명 된 인증서를 사용하는 경우 호스트 확인을 해제하는 것이 중요합니다. Verify-Host "false";이 작업을 수행하지 않으면 “오류가 발생합니다. SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

이제 저장소에 대한 무단 액세스가 더 이상 없습니다. 그래서 이것은 매우 유용하고 강력한 것입니다.

댓글

• 좋은 답변에 감사드립니다. 그러나 나는 여전히 주요 문제가 있다고 생각합니다. HTTPS는 특히 웹 및 데비안 패키지를 통한 전송을위한 기본 프로토콜이되어야합니다. 논쟁은 왜 HTTPS가 아니어야하는지, 왜 안될까요?
• @aalizadeh, 동의합니다. https를 사용할 때 오버 헤드가 있지만 엄청난 오버 헤드는 없습니다. https가 기본 전송이 아닌 주된 이유는 일부 조직이 암호화 된 트래픽을 명시 적으로 금지하기 때문이라고 생각합니다 (직원이 인터넷을 통해 수행하는 작업에 집중할 수 있기를 원하기 때문에). 즉, 저장소가 지원해야 함을 의미합니다. http 및 https 전송 모두. 다른 고려 사항이있을 수 있습니다.
• » Verify-Host ” false “; «는 자체 서명 된 인증서에서도 잘못되었습니다. 대신 클라이언트가 (올바른) 서버 인증서를 인식하도록해야합니다.
• 사실,하지만 여기서 내 클라이언트는 내부 시스템 일뿐입니다. 따라서 모든 적절한 pki 인프라를 만드는 대신 모서리를 잘라 냈습니다. 그리고 예, 나중에 pki가 제대로 정해졌고 Verify-Host가 거짓입니다. 제거되었습니다. 그리고 예, 요점은 유효합니다.
• ubuntu xenial을 사용하면 apt 패키지가 권한이없는 사용자 _apt로 가져옵니다. 파일 권한 문제를 관리하거나 해결 한 방법에 대한 세부 정보로이 스레드를 업데이트 할 수 있습니까?

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

… InRelease 서명을 우회합니다. 어쨌든 HTTPS를 구성하는 것이 좋습니다.

이것은 “단일 예가 아닙니다. HTTP로 기본 설정된 다른 많은 업데이트 시스템에도 서명 확인 실패 기록이 있습니다.

보안에 중요한 업데이트 메커니즘은 HTTPS 와 서명 확인은 강력합니다. 각각은 서로의 실패를 완화합니다.

댓글

• 이제 다음 항목도 있습니다. mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease 서명은 충분하지 않습니다 . ” 그러나 모든 미러를 HTTPS로 이동하려면 시간과 조정이 필요합니다! “. 예. 지금 시작하세요. 이것은 마지막 InRelease 실패가 아닙니다.
• 여기 ‘ 다른 생태계의 또 다른 예인 Alpine이 있습니다. 패키지 관리 시스템은 ‘ 기본적으로 HTTPS를 사용하지 않으며 서명에만 의존하여 패키지 무결성을 확인합니다.2018 년 9 월에 해당 확인에 원격으로 악용 가능한 버그가있었습니다. justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine이 시작됩니다. 지금 을 기본적으로 HTTPS를 사용하도록 전환합니다.
• (전체 공개 : 내 요점이지만 ‘이 내가 아는 유일한 참조입니다. of), 내가 알고있는 클라이언트 측 서명 확인 실패의 모든 실패 목록은 ‘입니다. 목록의 크기는 사소하지 않으며 정기적으로 증가합니다. 환영을 추가합니다. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

익명 성사용 사례의 경우 apt-transport-tor도 있습니다. 그러면 tor+http://와 같은 URI를 sources.list 파일. 이것은 단순히 미러에 대한 연결을 암호화하는 것보다 훨씬 더 나은 익명 성 보호입니다.

예를 들어, 로컬 관찰자는 여전히 사용자가 “HTTPS로도 소프트웨어를 업데이트하거나 설치하고 있음을 알고 있으며 적절한 추측을 할 수 있습니다.” 어떤 작업을 수행하고 있는지 (그리고 크기에 따라 어떤 패키지도 가능)

Debian은 Tor “Onion services”를 통해 APT 저장소를 제공하므로 종단 간 암호화를 얻을 수 있습니다 (비슷한 도메인 이름 시스템을 신뢰하지 않아도됩니다. 이 방법으로 사용할 수있는 모든 Debian 서비스는 onion.debian.org 를 참조하세요. 기본 Debian FTP 저장소는 vwakviie2ienjx6t.onion