Безопасно ли использовать sslverify => true для wp_remote_get / wp_remote_post

Обычно я использую этот аргумент для предотвращения ошибок с помощью wp_remote_get и wp_remote_post

 array( 'sslverify' => false ) 

По соображениям безопасности я хотел бы установить его в true (или удалить его, поскольку по умолчанию это правда).

Должен ли я ожидать каких-либо проблем, выполняя это?

TL; DR: Да, удалите эту настройку с WordPress 3.7 или более поздней.

В прошлом многие люди добавляли параметр sslverify = false именно потому, что их установка PHP не смогла надлежащим образом проверить сертификат.

Как правило, это связано с тем, что установка PHP не была обновлена ​​последней копией сертификатов CA Root. Коренные сертификаты меняются каждый раз так часто, и обычно вы не замечаете этого изменения, потому что это происходит в обычных обновлениях браузера. Ну, когда у вас есть PHP, действующий как браузер для извлечения https-адресов, ему также нужны эти обновления корневого сертификата. И большинство хостов никогда не обновляют PHP и не обновляют какую-либо определенную часть (например, файл сертификатов).

Когда WordPress реализовал автоматическое обновление в версии 3.7, было установлено, что необходимо обновить API WordPress.org, чтобы требовать безопасной связи. В это время WordPress начал включать копию самого файла CA Root Certificates, полученную из Mozilla. Поскольку WordPress 3.7 поэтому функции API WP_HTTP используют этот файл для проверки сертификата, а не старая или устаревшая версия, упакована с вашей установкой PHP.

Поэтому да, с WordPress 3.7 или более поздней версией, рекомендуется удалить параметр sslverify и позволить функциям http выполнять правильную проверку сертификата. Любой современный сервер, на котором запущен SSL с ключом, подписанным одним из известных ЦС, будет проверен правильно. WP_HTTP должен иметь копию последних корневых сертификатов, а основной проект будет обновлять этот файл сертификатов в WordPress вместе с обычными обновлениями.

Существует множество причин, по которым проверка SSL может завершиться неудачей. Начиная с слишком большого количества перенаправлений на неправильные .ini файлы / настройки или просто отсутствующие сертификаты или поддомены. В любом случае вам нужно будет найти причину этого и исправить . Об этом нет .

Но чтобы временно решить эту проблему (скажем, вам нужно еще раз разработать свой код и исправить ошибку SSL), вы можете использовать фильтр:

 add_filter( 'https_ssl_verify', '__return_false' ); 

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

 add_filter( 'http_request_args', function( $params, $url ) { // find out if this is the request you are targeting and if not: abort if ( 'foo' !== $params['foo'] ) return $params; add_filter( 'https_ssl_verify', '__return_false' ); return $params; }, 10, 2 ); 

Если это общедоступный плагин, вы можете захотеть прикрепить его к простой опции, которую пользователь может включить или выключить. Вы также можете попробовать проверенный запрос, а если нет (и если пользователь выбрал неподписанный запрос), переключитесь на потенциально опасный запрос.

Практическое правило:

Никогда не выполняйте необеспеченный запрос, пока ваш пользователь не согласится сделать это и не знает о рисках.

WordPress может полагаться на основное программное обеспечение сервера (обычно cURL) для выполнения сетевого запроса. В двух словах, потому что это то, что это программное обеспечение хорошо и есть.

На некоторых серверах по разным причинам (я никогда не задумывался о себе) довольно типично, что серверное программное обеспечение не может «проверять» защищенные соединения, производя указанные ошибки.

Так:

  • если это частный код на серверах, которыми вы управляете, вы должны убедиться, что серверы правильно обрабатывают запросы, и этот параметр не отключен
  • если это код для общего распространения, вы, вероятно, тоже не хотите его отключать, но если он будет достаточно популярен, он окажется на серверах, где в какой-то момент он сломается, и вам придется поддерживать это в определенной форме (сообщая людям что надлежащая конфигурация, как ожидается, обеспечит настройку для ее отключения для ваших запросов и т. д.),