왜 데비안 apt 도구에 대한 https 전송이 없습니까?

NSA 계시와 함께 제공되는 모든 편집증과 함께 데비안 패키지 설치 메커니즘이 기본적으로 사용하지 않고 왜 전송을 위해 HTTPS를 지원하지 않는지 궁금합니다.

데비안 패키지에는 GPG를 사용하여 일종의 서명 유효성 검사가 있다는 것을 알고 있지만 보안이 얼마나 중요한지 고려할 때 여전히 HTTP 대신 HTTPS 전송을 사용하는 것이 너무 어렵다고 생각하지 않습니다.

편집 : 나는 데비안 미러 관리자가 아닌 MitM 공격 (트래픽 스니핑 포함)으로부터 자신을 보호하고 싶습니다. 누군가가 데비안 미러로 이동하는 트래픽을 스누핑하면 HTTP 리포지토리가 전체 시스템 설정을 테이블에 배치합니다.

있습니다. 패키지를 설치해야합니다 apt-transport-https. 그런 다음과 같은 줄을 사용할 수 있습니다

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

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

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

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

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

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

HTTPS가 도움이되는 곳은 알려진 올바른 설치 이미지를 얻는 것입니다. 데비안은 다음을 제공하지 않는 것 같습니다 : 설치 미디어의 체크섬이 있지만 HTTP를 통해서만 제공됩니다.

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

이 경우 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에 넣고 우분투의 경우 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://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

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

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

예를 들어, 로컬 관찰자는 여전히 HTTPS를 사용하여 소프트웨어를 업데이트하거나 설치하고 있음을 알고 있으며 현재 수행중인 패키지와 크기에 따라 패키지를 추정 할 수 있습니다.

데비안은 Tor "Onion services"를 통해 APT 리포지토리를 제공하므로 도메인 이름 시스템을 신뢰하지 않고도 종단 간 암호화 (TLS와 유사)를 얻을 수 있습니다. 이 방법으로 사용 가능한 모든 데비안 서비스는 onion.debian.org 를 참조하십시오 . 주요 데비안 FTP 저장소는vwakviie2ienjx6t.onion