31.18. Поддержка SSL

31.18.1. Проверка сертификатов сервера на стороне клиента

По умолчанию PostgreSQL не выполняет никакие проверки сертификата сервера. Это означает, что клиента можно ввести в заблуждение, подменив сервер (например, изменив запись в DNS или заняв его IP-адрес). Чтобы предотвратить подобную подмену, необходимо включить проверку сертификатов SSL.

Если в sslmode выбран режим verify-ca, libpq будет определять, можно ли доверять серверу, проверяя всю цепочку сертификатов до доверенного центра сертификации (ЦС). Если режим sslmode — verify-full, libpq будет также проверять, соответствует ли имя сервера имени в сертификате. Подключение SSL не будет установлено, если проверить сертификат сервера не удастся. В максимально защищённых окружениях рекомендуется использовать режим verify-full.

В режиме verify-full атрибут cn (Общее имя) сертификата сверяется с именем компьютера. Если атрибут cn начинается со звёздочки (*), он будет воспринят как маска, и этой звёздочке будут соответствовать все символы, кроме точки (.). Это означает, что такой сертификат не будет соответствовать поддоменам. Если подключение устанавливается по IP-адресу, а не по имени компьютера, проверяться будет IP-адрес (без поиска в DNS).

Чтобы можно было проверить сертификат сервера, файл ~/.postgresql/root.crt в домашнем каталоге пользователя должен содержать сертификат(ы) одного или нескольких доверенных ЦС. Если root.crt содержит сертификаты промежуточных ЦС, он также должен содержать цепочки сертификатов до их корневого ЦС. (В Microsoft Windows этот файл называется %APPDATA%\postgresql\root.crt.)

Если существует файл ~/.postgresql/root.crl (или %APPDATA%\postgresql\root.crl в Microsoft Windows), при проверке также учитывается содержащийся в нём список отозванных сертификатов (CRL, Certificate Revocation List).

Размещение файла корневых сертификатов и CRL можно поменять, задав параметры соединения sslrootcert и sslcrl или переменные окружения PGSSLROOTCERT и PGSSLCRL, соответственно.

31.18.2. Клиентские сертификаты

Если сервер запрашивает доверенный клиентский сертификат, libpq передаёт ему сертификат из файла ~/.postgresql/postgresql.crt в домашнем каталоге пользователя. Этот сертификат должен быть подписан одним из центром сертификации (ЦС), доверенным для сервера. Также должен присутствовать закрытый ключ в файле ~/.postgresql/postgresql.key. Файл закрытого ключа не должен быть доступен всем или группе; этого можно добиться командой chmod 0600 ~/.postgresql/postgresql.key. В Microsoft Windows эти файлы называются %APPDATA%\postgresql\postgresql.crt и %APPDATA%\postgresql\postgresql.key, и никакие специальные проверки не производятся, так как предполагается, что этот каталог безопасен. Размещение файлов сертификата и ключа можно переопределить параметрами соединения sslcert и sslkey, либо переменными окружения PGSSLCERT и PGSSLKEY, соответственно.

В некоторых случаях сертификат клиента может подписываться "промежуточным" центром сертификации, сам сертификат не обязательно должен быть доверенным для сервера. Чтобы использовать такой сертификат, нужно добавить в файл postgresql.crt сертификат выдавшего его центра сертификации, затем сертификат вышестоящего центра и так далее, до сертификата "корневого" или "промежуточного" центра, которому доверяет сервер. Сервер считает сертификат доверенным, если он подписан сертификатом, содержащимся в его собственном файле root.crt.

Заметьте, что файл ~/.postgresql/root.crt на клиенте содержит сертификаты центров сертификации верхнего уровня, которые считаются доверенными для подписания серверных сертификатов. В принципе в нём может отсутствовать сертификат ЦС, подписавшего сертификат клиента, хотя в большинстве случаев этот ЦС также будет доверенным для клиентских сертификатов.

31.18.3. Защита, обеспечиваемая в различных режимах

Разные значения параметра sslmode обеспечивают разные уровни защиты. SSL позволяет защититься от следующих типов атак:

Чтобы соединение было гарантированно безопасном, SSL должен быть настроен на клиенте и на сервере, прежде чем будет установлено соединение. Если он настроен только на сервере, клиент может начать передавать важную информацию (например, пароли), до того как поймёт, что сервер требует высокого уровня безопасности. В libpq для установления безопасных соединений нужно задать для параметра sslmode значение verify-full или verify-ca и предоставить системе корневой сертификат для проверки. В качестве аналогии можно привести использование адреса с https для безопасного просмотра веб-содержимого.

Когда подлинность сервера подтверждена, клиент может передавать конфиденциальные данные. Это значит, что до этого момента клиенту не нужно знать, применяются ли сертификаты для аутентификации, так что настройка использования сертификатов только на стороне сервера не угрожает безопасности.

Все варианты использования SSL подразумевают издержки шифрования и обмена ключами, что порождает необходимость выбора между производительностью и безопасностью. В Таблица 31-1 описываются риски, от которых защищают различные варианты sslmode, и приводятся утверждения относительно защиты и издержек.

Различие вариантов verify-ca и verify-full зависит от характера корневого ЦС. Если используется публичный ЦС, режим verify-ca допускает подключение к серверу с сертификатом, который получил кто угодно в этом ЦС. В такой ситуации нужно всегда использовать режим verify-full. Если же используется локальный ЦС или даже самоподписанный сертификат, режим verify-ca обычно обеспечивает достаточную защиту.

По умолчанию параметр sslmode имеет значение prefer. Как показано в этой таблице, он не имеет большого смысла с точки зрения безопасности, и даёт только выигрыш в производительности, если это возможно. Он выбран по умолчанию для обратной совместимости и не рекомендуется для защищённых окружений.

31.18.4. Файлы, используемые клиентом SSL

В Таблице 31-2 перечислены файлы, имеющие отношение к настройке SSL на стороне клиента.

31.18.5. Инициализация библиотеки SSL

Если ваше приложение инициализирует библиотеку libssl и/или libcrypto, и libpq собрана с поддержкой SSL, вы должны вызвать PQinitOpenSSL, чтобы сообщить libpq, что библиотека libssl и/или libcrypto уже инициализированы вашим приложением, чтобы libpq не пыталась ещё раз инициализировать их. Более подробно API SSL описано на странице http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html.