apt-transport-https - Transporte APT para download através do protocolo HTTP Secure (HTTPS)
Esse transporte APT permite o uso de repositórios acessados por meio do protocolo HTTP Secure (HTTPS), também conhecido como HTTP sobre TLS. Ele está disponível por padrão desde o apt 1.5 e estava disponível antes disso no pacote apt-transport-https. Observe que um transporte nunca é chamado diretamente por um usuário, mas usado por ferramentas APT com base na configuração do usuário.
HTTP é por si só um protocolo de transporte não criptografado (compare apt-transport-http(1)), que, conforme indicado pelo S anexado, é envolto em uma camada criptografada conhecida como Transport Layer Security (TLS) para fornecer criptografia de ponta a ponta. Um invasor suficientemente capaz ainda pode observar os parceiros de comunicação e uma análise mais profunda da comunicação criptografada ainda pode revelar detalhes importantes. Uma visão geral dos métodos alternativos de transporte disponíveis é fornecida em sources.list(5).
O protocolo HTTPS é baseado no protocolo HTTP, então todas as opções suportadas por apt-transport-http(1) também estão disponíveis via Acquire::https e terão como padrão os mesmos valores especificados para Acquire:: http. Esta página de manual documentará apenas as opções exclusivas para https.
Por padrão, todos os certificados confiáveis pelo sistema (consulte o pacote ca-certificates) são usados para a verificação do certificado do servidor. Uma autoridade de certificação (CA) alternativa pode ser configurada com a opção Acquire::https::CAInfo e sua opção específica de host Acquire::https::CAInfo::host. A opção CAInfo especifica um arquivo composto de certificados CA (no formato PEM) concatenados para criar a cadeia que o APT deve usar para verificar o caminho de seu certificado raiz autoassinado. Se o servidor remoto fornecer toda a cadeia durante a troca, o arquivo precisará conter apenas o certificado raiz. Caso contrário, toda a cadeia é necessária. Se você precisar oferecer suporte a várias autoridades, a única maneira é concatenar tudo.
Uma lista personalizada de certificados revogados (CRL) pode ser configurada com as opções Acquire::https::CRLFile e Acquire::https::CRLFile::host. Como na opção anterior, é necessário especificar um arquivo no formato PEM.
Durante a autenticação do servidor, se a verificação do certificado falhar por algum motivo (expirado, revogado, man in the middle, etc.), a conexão falhará. Obviamente, isso é o que você deseja em todos os casos e o que o valor padrão (verdadeiro) da opção Acquire::https::Verify-Peer e sua variante específica do host fornecem. Se você souber exatamente o que está fazendo, definir esta opção como "falso" permite que você pule a verificação do certificado de mesmo nível e faça a troca ser bem-sucedida. Novamente, esta opção é apenas para fins de depuração ou teste, pois remove toda a segurança fornecida pelo uso de HTTPS.
Da mesma forma, a opção Acquire::https::Verify-Host e sua variante específica do host podem ser usadas para desativar um recurso de segurança: O certificado fornecido pelo servidor inclui a identidade do servidor que deve corresponder ao nome DNS usado para acessá-lo. Por padrão, conforme solicitado pelo RFC 2818, o nome do espelho é verificado em relação à identidade encontrada no certificado. Este comportamento padrão é seguro e não deve ser alterado, mas se você sabe que o servidor que você está usando possui um nome DNS que não corresponde à identidade em seu certificado, você pode definir a opção como "falso", o que impedirá a comparação de ser executado.
Além de oferecer suporte à autenticação baseada em senha (consulte apt_auth.conf(5)), o HTTPS também oferece suporte à autenticação baseada em certificados de cliente via Acquire::https::SSLCert e Acquire::https::SSLKey. Estes devem ser definidos respectivamente com o nome do arquivo do certificado do cliente X.509 e a chave privada (não criptografada) associada, ambos no formato PEM. Na prática, o uso das variantes específicas do host de ambas as opções é altamente recomendado.
Acquire::https { Proxy::example.org "DIRECT"; Proxy "socks5h://apt:pass@127.0.0.1:9050"; Proxy-Auto-Detect "/usr/local/bin/apt-https-proxy-auto-detect"; No-Cache "true"; Max-Age "3600"; No-Store "true"; Timeout "10"; Dl-Limit "42"; Pipeline-Depth "0"; AllowRedirect "false"; User-Agent "My APT-HTTPS"; SendAccept "false"; CAInfo "/path/to/ca/certs.pem"; CRLFile "/path/to/all/crl.pem"; Verify-Peer "true"; Verify-Host::broken.example.org "false"; SSLCert::example.org "/path/to/client/cert.pem"; SSLKey::example.org "/path/to/client/key.pem" };
apt-transport-http(1) apt.conf(5) apt_auth.conf(5) sources.list(5)
Página de bug do APT[1]. Se você deseja reportar um bug no APT, por favor veja /usr/share/doc/debian/bug-reporting.txt ou o comando reportbug(1).
Equipe APT
1. Página de bug do APT: http://bugs.debian.org/src:apt