Невозможно установить соединение SSL только с первой попытки

У меня есть веб-сайт электронной коммерции, который работает в течение нескольких месяцев без изменений кода (и в течение нескольких лет с минимальными изменениями в пути обработки карт). Теперь у меня есть проблема, когда при первом открытии соединения с защищенным сервером процессора кредитных карт соединение не устанавливается. При второй (или третьей, или четвертой и т. Д.) Попытке соединение успешно установлено. Через некоторое время — возможно, 5 минут — начальное соединение снова не будет установлено, а последующие соединения будут успешными.

Пример кода, который приходит из файла PHP API процессора кредитной карты:

$url = 'https://esplus.moneris.com:443/gateway_us/servlet/MpgRequestArray';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt ($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$dataToSend);
curl_setopt($ch,CURLOPT_TIMEOUT,$gArray[CLIENT_TIMEOUT]);
curl_setopt($ch,CURLOPT_USERAGENT,$gArray[API_VERSION]);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE);

$response=curl_exec ($ch);

if(!$response) {
print curl_error($ch);
print "\n";
print curl_errno($ch);
print "\n";
} else {
print "Success\n";
}

Выход:

% php tester_curl.php
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
35
% php tester_curl.php
Success
% php tester_curl.php
Success
% php tester_curl.php
Success

Есть некоторые похожие вопросы, но мне не удалось решить проблему, и я не вижу ни одного с таким же сообщением об ошибке и признаком последующих попыток подключения, которые успешно завершаются после первоначального сбоя, например:

0

Решение

Сервер вроде сломан. Это поддерживает TLS1.2 и TLS1.0, но не TLS1.1 (отвечает с TLS1.0, который в порядке). Обычно это не проблема, если у вас нет клиентского кода, который пытается применить определенные протоколы, исключая другие.

Поведение, которое вы описываете, выглядит как клиент, который понижает соединение при неудачном соединении, сохраняет это кэширование в течение некоторого времени, но через некоторое время повторяет попытку с первоначально ошибочной версией. Чтобы отследить проблему:

  • проверьте, не связана ли проблема также с другими серверами
  • проверьте, есть ли у других клиентов проблемы с тем же сервером
  • проверьте базовую реализацию. Curl может использовать GnuTLS, NSS, OpenSSL и, возможно, больше. Из сообщения об ошибке это выглядит как OpenSSL, но какой версии?
  • проверьте наличие промежуточного звена (брандмауэр, балансировщик нагрузки …) на пути к серверу, который может вызвать проблемы
  • выполните захват пакета и опубликуйте его здесь в форме, пригодной для использования с wireshark (например, cloudshark)

Для получения дополнительной информации о том, как отладить такого рода проблемы и какую дополнительную информацию было бы полезно проверить http://noxxi.de/howto/ssl-debugging.html#aid_external_debugging

1

Другие решения

У меня была точная вещь, случившаяся с клиентом, использующим старый шлюз VirtualMerchant. Он начал терпеть неудачу в 5:00 вечера в понедельник и волшебным образом начал работать снова в 10:00 на следующий день.

Будь то в командной строке через openssl, или curl, или через curl в PHP, соединение будет разорвано в первый раз, а затем, если вы запустите ту же команду во второй раз, оно будет работать.

Я пытался форсировать IPv4 (вместо IPv6), устанавливать тайм-ауты, форсировать различные протоколы, понижать версию openssl и т. Д., И ничего из этого не работало.

Предполагается, что это было что-то, связанное с DNS и / или сервером на стороне шлюза, потому что мы ничего не исправили, и он исправил сам.

Мы работали с более старым openssl, который поддерживал только до TLS 1.1, но он работал, а потом снова начал работать, так что это был не только наш клиент. Тем не менее, возраст нашего клиента, должно быть, был частью проблемы, потому что другие новые клиенты не испытывали «неудачу первой попытки» в течение того же периода времени.

Короче говоря, если это произойдет, то это, вероятно, не ВЫ (кроме того, что у вас более старый OpenSSL), и другой шлюз / сервер, которому вы звоните, вероятно, возможно, потребуется что-то исправить / настроить, чтобы он снова начал работать.

Имейте в виду, openssl является частью основных пакетов Linux, поэтому вы не можете просто обновить openssl без серьезного риска испортить ваш сервер. Вам придется перейти на более новую версию операционной системы, чтобы получить более современный openssl.

0

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector