PayPal обновляет сертификаты SSL на всех конечных точках сети и API. Из-за проблем безопасности, связанных с достижениями в вычислительной мощности, отрасль постепенно отказывается от 1024-битных сертификатов SSL (G2) в пользу 2048-битных сертификатов (G5) и переходит к более надежному алгоритму шифрования данных для защиты передачи данных, SHA. -2 (256) по сравнению со старым стандартом алгоритма SHA-1.
Однако мы все еще используем системы, несовместимые с обновлениями, и обновление наших серверов не является вариантом. Итак, мы думаем, что нужно проксировать (nginx) конечную точку PayPal, чтобы PayPal считал, что сервер nginx (который поддерживает обновление) попадает в эту конечную точку вместо наших старых серверов. Это возможно? Если нет, каковы возможные варианты обойти это обновление?
Вот пример конфигурации прокси nginx
server {
listen 80;
server_name api.sandbox.paypal.com;
access_log /var/log/nginx/api.sandbox.paypal.com.access.log;
error_log /var/log/nginx/api.sandbox.paypal.com.error.log;
location /nvp {
proxy_pass https://api.sandbox.paypal.com/nvp;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
} Это не столько обновление, сколько возможность перестроить и рефакторинг. Как долго эти системы RHEL4 находятся в производстве? 2006? 2007?
Ваша организация игнорировала График жизненного цикла Red Hat и предупреждения об окончании периода поддержки? Означает ли это, что все эти системы не имеют себе равных с момента последних выпусков пакетов?
Можете ли вы объяснить, почему вы все еще пользуетесь RHEL4? В 2012 году он действительно подошел к концу. В то время была возможность просто восстановить.
Для этой конкретной проблемы я думаю, что лучший подход - оценить усилия по перестроению на более современную ОС. EL6 или EL7 были бы хорошими кандидатами и подпадали бы под активную поддержку.
Идти против ветра так сложно (и в данном случае бесполезно), так почему бы вам вместо этого не пойти по нему? Я понимаю, что обновление иногда может быть головной болью, но оно того стоит.
Кроме того, невозможно работать с 2048-bit сертификаты все же приведут вас к еще большему количеству проблем в ближайшие несколько лет. Думаю, не только PayPal, но и многие другие сервисы забудут о 1024-bit и неспособность следить за обновлениями приведет к тому, что вы сошли с ума, заставляя все работать.
В принципе, я не вижу причин, по которым использование прокси не сработает. Я недостаточно знаю о nginx, чтобы знать, будет ли работать эта конкретная конфигурация или нет.
Другой вариант, который, возможно, стоит рассмотреть, - это обновление библиотеки ssl / tls и корневого хранилища сертификатов без обновления ОС в целом. Очевидно, это потребует некоторого уровня тестирования совместимости / регрессии и, вероятно, потребует создания рассматриваемой библиотеки из исходного кода.
Если вы не можете обрабатывать современные сертификаты (от корня> = 2048 бит и с подписями sha256), в ближайшем будущем у вас начнутся проблемы практически с любой службой ssl, а не только с PayPal.
Как заметил ewwhite, RHEL4 является EOL с 2012 г..
Почему вы не можете обновиться? Если проблема заключается в стоимости лицензирования, есть CentOS. Если проблема в какой-то зависимости кода, ммм. У меня нет бойкого ответа на этот вопрос, как у меня по поводу стоимости, но со временем ситуация будет только ухудшаться.
Я бы понял, если бы это была какая-то устаревшая вещь, которую вы должны были держать под рукой по причинам соблюдения законодательства (и держать подальше от Интернета), но вы говорите о вашей реальной сфере деятельности. Вы не хотите становиться статистиком. Напоминаем: Home Depot потрачено 43 000 000 долл. США об их утечке данных.
Пожалуйста, пересмотрите позицию «обновление наших серверов не является вариантом».