apt-transport-https - справочное руководство, опции, примеры команд


ИМЯ

apt-transport-https - APT-транспорт для загрузки по защищенному протоколу HTTP (HTTPS).

ОПИСАНИЕ

Этот транспорт APT позволяет использовать репозитории, доступ к которым осуществляется через защищенный протокол HTTP (HTTPS), также называемый HTTP через TLS. Он доступен по умолчанию, начиная с версии apt 1.5, а до этого был доступен в пакете apt-transport-https. Обратите внимание, что транспорт никогда не вызывается пользователем напрямую, а используется инструментами APT на основе конфигурации пользователя.

HTTP сам по себе является незашифрованным транспортным протоколом (сравните apt-transport-http(1)), который, как указано буквой S в конце, заключен в зашифрованный уровень, известный как безопасность транспортного уровня (TLS). обеспечить сквозное шифрование. Злоумышленник с достаточными способностями все еще может наблюдать за партнерами по связи, и более глубокий анализ зашифрованной связи может выявить важные детали. Обзор доступных альтернативных методов транспортировки приведен в sources.list(5).

ПАРАМЕТРЫ

Протокол HTTPS основан на протоколе HTTP, поэтому все параметры, поддерживаемые apt-transport-http(1), также доступны через Acquire::https и по умолчанию имеют те же значения, что и для Acquire:: http. Эта справочная страница будет документировать только параметры, уникальные для https.

Учетные данные сервера

По умолчанию все сертификаты, которым доверяет система (см. пакет ca-certificates), используются для проверки сертификата сервера. Альтернативный центр сертификации (ЦС) можно настроить с помощью параметра Acquire::https::CAInfo и его параметра Acquire::https::CAInfo::host для конкретного узла. Параметр CAInfo указывает файл, состоящий из сертификатов ЦС (в формате PEM), соединенных вместе для создания цепочки, которую APT должен использовать для проверки пути от вашего самозаверяющего корневого сертификата. Если удаленный сервер предоставляет всю цепочку во время обмена, файл должен содержать только корневой сертификат. В противном случае требуется вся цепочка. Если вам нужно поддерживать несколько авторитетов, единственный способ — объединить все.

Пользовательский список отзыва сертификатов (CRL) можно настроить с помощью параметров Acquire::https::CRLFile и Acquire::https::CRLFile::host. Как и в предыдущем варианте, необходимо указать файл в формате PEM.

Отключение безопасности

Если во время проверки подлинности сервера по какой-либо причине не удается выполнить проверку сертификата (истек срок действия, отозван, человек посередине и т. д.), соединение не устанавливается. Это, очевидно, то, что вам нужно во всех случаях, и то, что обеспечивает значение по умолчанию (true) параметра Acquire::https::Verify-Peer и его варианта для конкретного хоста. Если вы точно знаете, что делаете, установив для этого параметра значение "false", вы сможете пропустить проверку однорангового сертификата и сделать обмен успешным. Опять же, этот параметр предназначен только для целей отладки или тестирования, поскольку он удаляет всю безопасность, обеспечиваемую использованием HTTPS.

Точно так же параметр Acquire::https::Verify-Host и его вариант для конкретного хоста можно использовать для деактивации функции безопасности: сертификат, предоставленный сервером, включает идентификатор сервера, который должен соответствовать DNS-имени, используемому для доступа к нему. По умолчанию, как того требует RFC 2818, имя зеркала сверяется с идентификатором, найденным в сертификате. Это поведение по умолчанию является безопасным и его не следует изменять, но если вы знаете, что DNS-имя используемого вами сервера не соответствует идентификатору в его сертификате, вы можете установить для параметра значение «false», что предотвратит сравнение. от исполнения.

Аутентификация клиента

Помимо поддержки аутентификации на основе пароля (см. apt_auth.conf(5)) HTTPS также поддерживает аутентификацию на основе клиентских сертификатов через Acquire::https::SSLCert и Acquire::https::SSLKey. Они должны быть установлены соответственно имени файла сертификата клиента X.509 и связанного (незашифрованного) закрытого ключа, оба в формате PEM. На практике настоятельно рекомендуется использовать специфичные для хоста варианты обоих вариантов.

ПРИМЕРЫ

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)

ОШИБКИ

Страница ошибки APT[1]. Если вы хотите сообщить об ошибке в APT, см. /usr/share/doc/debian/bug-reporting.txt или команду reportbug(1).

АВТОР

Команда APT

ПРИМЕЧАНИЯ

1. Страница ошибок APT: http://bugs.debian.org/src:apt