Я думаю, что (в настоящее время, по состоянию на IO::Socket::SSL
2.056) нет чистого способа сделать это.
Но так как это Perl, это можно сделать с помощью некоторого исправления обезьяны.Так как проверку лучше всего выполнять сразу после успешного подключения к серверу, можно использовать оболочку около IO::Socket::SSL::connect_SSL
для получения сокета SSL, выполните проверку OCSP и разрешите неудачное соединение, если проверка OCSP привела к ошибкам:
use strict;
use warnings;
use IO::Socket::SSL;
use LWP::UserAgent;
{
my $old = \&IO::Socket::SSL::connect_SSL;
no warnings 'redefine';
*IO::Socket::SSL::connect_SSL = sub {
my $sock = $old->(@_) or return;
my $ocsp = $sock->ocsp_resolver;
if (my $errors = $ocsp->resolve_blocking()) {
warn $errors;
close($sock);
return;
}
return $sock;
}
}
my $ua = LWP::UserAgent->new();
$ua->ssl_opts(SSL_ocsp_mode => SSL_OCSP_FULL_CHAIN|SSL_OCSP_FAIL_HARD|SSL_OCSP_NO_STAPLE);
my $resp = $ua->get('https://revoked.grc.com');
print $resp->decoded_content;
Обратите внимание, что это исправление обезьяны является глобальным, то есть затрагивает все IO::Socket::SSL
объекты, а не только тот, который используется в LWP::UserAgent
.Так что это может иметь некоторые непреднамеренные побочные эффекты при использовании в более сложной программе, чем в этом примере.Более чистый дизайн мог бы иметь некоторый пользовательский обратный вызов после подключения.Возможно, я добавлю этот тип функциональности в IO::Socket::SSL
, но пока этот хак должен работать.
Обратите внимание также, что resolve_blocking
не использует объект LWP::UserAgent
, а опирается на HTTP::Tiny
.Таким образом, любые настройки, специфичные для LWP::UserAgent
подобных прокси, не будут иметь никакого эффекта.Если это проблема, вы можете выполнить запросы вручную и передать их в объект распознавателя OCSP, используя $ocsp->requests
для получения запросов и $ocsp->add_response
для передачи ответа в объект распознавателя.