После выполнения склонного - добираются, сценарии Perl dist-обновления больше не будут игнорировать недопустимые сертификаты SSL на 14,04

Доброе утро все,

На прошлой неделе я решил выполнить команды к пакетам обновления на моих 14.04 Серверах, чтобы гарантировать, что я был исправлен для недавно найденных уязвимостей Bash. На информацию здесь (http://www.ubuntu.com/usn/usn-2362-1/) я работал, Кв. - получают dist-обновление. Для ссылки я работал склонный - получают обновление, склонный - получают dist-обновление, и затем склонный - заставляют обновление пробовать и удостоверяться, что у меня было все до последних версий (я обычно работаю, Кв. - получают обновление хотя).

После успешного выполнения этого я нашел, что много моих сценариев Perl больше не функционировали. Для ссылки я использую этот сервер для Nagios для контроля всех моих других серверов. Рассматриваемые сценарии, которые теперь приводят все подключение к сбою к системе через https, входят в хост и запрашивают различные биты информации.

До обновления я смог добавить строку к каждому из моих сценариев Perl, чтобы заставить его проигнорировать SSL:

$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0 } 

Однако после обновления, это, кажется, не имеет никакого влияния и сценариев весь сбой, потому что они не могут проверить сертификаты SSL (все сам подписанный).

Вот некоторые надрезы того, что я вижу:

выполнение сценария:

    nagios@nagios:/usr/local/nagios/libexec$ ./check_esx.pl -H 192.168.22.18 -u root -p password -l cpu
CHECK_ESX.PL CRITICAL - Can't connect to 192.168.22.18:443 (certificate verify failed)

LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/share/perl5/LWP/Protocol/http.pm line 41.

Этот конкретный сценарий Perl использует "Инструментарий Perl инфраструктуры VMware (VI)" для функционирования. Сценарий, который я называю, check_esx.pl, доступен здесь

Вот надрез файла http.pm вокруг строки, на которую ссылаются по вышеупомянутой ошибке; строка 41 является "умереть" строкой.

sub _new_socket
{
    my($self, $host, $port, $timeout) = @_;

    local($^W) = 0;  # IO::Socket::INET can be noisy
    my $sock = $self->socket_class->new(PeerAddr => $host,
                                        PeerPort => $port,
                                        LocalAddr => $self->{ua}{local_address},
                                        Proto    => 'tcp',
                                        Timeout  => $timeout,
                                        KeepAlive => !!$self->{ua}{conn_cache},
                                        SendTE    => 1,
                                        $self->_extra_sock_opts($host, $port),
                                       );

    unless ($sock) {
        # IO::Socket::INET leaves additional error messages in $@
        my $status = "Can't connect to $host:$port";
        if ($@ =~ /\bconnect: (.*)/ ||
            $@ =~ /\b(Bad hostname)\b/ ||
            $@ =~ /\b(certificate verify failed)\b/ ||
            $@ =~ /\b(Crypt-SSLeay can't verify hostnames)\b/
        ) {
            $status .= " ($1)";
        }
        die "$status\n\n$@";
    }

    # perl 5.005's IO::Socket does not have the blocking method.
    eval { $sock->blocking(0); };

    $sock;
}

Таким образом, я предполагаю то, что я ищу, вот одна из двух вещей

Также: (A) Существует ли новый/лучше/больше корректный способ заставить Perl проигнорировать сертификаты SSL? или (B) Существует ли способ импортировать сам, подписал сертификат SSL от другого хоста в Ubuntu так, чтобы сценарий Perl распознал и доверял ему? Кроме того: (B-2) Является там способом заставить Ubuntu распознать мои окна активный каталог Cert Authority, таким образом, что я мог выпустить сертификаты SSL от своего CA до рассматриваемых систем, и это распознало сценариями Perl?

Заранее спасибо все!

1
задан 6 October 2014 в 17:44

2 ответа

$ENV {PERL_LWP_SSL_VERIFY_HOSTNAME} = 0

Это было ошибкой в LWP (CVE-2014-3230), который был зафиксирован в более новых версиях. PERL_LWP_SSL_VERIFY_HOSTNAME только используется, чтобы опустить проверять имя узла в сертификате, не цепочку сертификата. Но, потому что Вы используете самоподписанную проверку цепочки сертификата, перестанет работать.

Эта опция была только представлена для миграции от старого Склепа:: бэкенд SSLeay к новому IO:: Сокет:: бэкенд SSL. Склеп:: SSLeay не поддерживает проверку имени узла (и таким образом открыто для атак "человек посередине"), в то время как IO:: Сокет:: SSL делает. С версией 6 LWP бэкенд по умолчанию является IO:: Сокет:: SSL.

Для завершенного отключения проверки сертификата устанавливает SSL_verify_mode => SSL_VERIFY_NONE (Вы должны к use IO::Socket::SSL иметь доступ к константе SSL_VERIFY_NONE, или просто использовать 0) в ssl_opts LWP. Нет никакой переменной среды, чтобы сделать это.

Пример:

use LWP::UserAgent;
use IO::Socket::SSL;
my $ua = LWP::UserAgent->new(..., ssl_opts => { SSL_verify_mode => SSL_VERIFY_NONE });
$ua->get(...); # or $ua->post(...) or $ua->request(...)

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

Что касается Ваших опций B:

(B) там способ импортировать сам, подписал сертификат SSL от другого хоста в Ubuntu так, чтобы сценарий Perl распознал & доверять ему? Кроме того: (B-2) Является там способом заставить Ubuntu распознать мои окна активный каталог Cert Authority, таким образом, что я мог выпустить сертификаты SSL от своего CA до рассматриваемых систем, и это распознало сценариями Perl?

необходимо быть в состоянии использовать переменную среды PERL_LWP_SSL_CA_FILE для определения файла, какая АВАРИЯ или самоподписал сертификаты, которые Вы принимаете, как доверяется.

1
ответ дан 11 November 2019 в 12:34

Я думаю, что это - проблема версии жемчуга, проверьте то, что сделала версия жемчуга Вы используете ранее для выполнения того сценария.

то, В чем я уверен, - то, что Ubuntu устанавливает последнюю стабильную версию каждого программного обеспечения. Возьмите, например, если у Вас есть python3 сценарий, который работает на человечности 12.04, она не могла бы работать над человечностью 14.04, и причиной этого являются ели, имеет python 3.2, когда версия latterhas python 3.4.

я предполагаю, что то же происходит с Вами сценарий жемчуга, проверяет версию жемчуга и информацию о версии новой версии.

0
ответ дан 11 November 2019 в 12:34

Другие вопросы по тегам:

Похожие вопросы: