Bypass Paypal Upgrade

Question

PayPal is making upgrades to the SSL certificates on all web and API endpoints. Due to security concerns over advances in computing power, the industry is phasing out 1024-bit SSL certificates (G2) in favor of 2048-bit certificates (G5), and is moving towards a higher strength data encryption algorithm to secure data transmission, SHA-2 (256) over the older SHA-1 algorithm standard.

However, we're still using systems that are not compatible with the upgrades and updating our servers is not an option. So, what we think is to proxy(nginx) the paypal endpoint so that paypal thinks that the nginx server(which supports the update) is hitting that endpoint instead of our old servers. Is this possible? if not, what are the possible options to bypass this upgrade?

Here is a sample config of the nginx proxy

 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;
    }
} 

Answer 1

This is less of an upgrade and more of an opportunity to rebuild and refactor. How long have these RHEL4 systems been in production? 2006? 2007?

Did your organization ignore the Red Hat lifecycle schedule and warnings about end of support periods? Does that mean all of these systems are running unmatched since the last package releases?

Can you give some reason about why you're still on RHEL4? That really went end-of-life in 2012. In that period of time, there's been opportunity to simply rebuild.

For this particular issue, I think the best approach is to gauge the effort to rebuild onto a more current OS. EL6 or EL7 would be good candidates and would fall under active support.

Answer 2

It's so hard (and in this case useless) walking against the wind so, why don't you follow it instead? I can understand that upgrading may be a pain in the ass sometimes but it's worth it.

Also, not being able to work with 2048-bit certificates yet will lead you in many more problems in the next few years. I guess not only paypal, but many other services will forget about 1024-bit and not being able to follow the upgrades will lead into you being crazy to make things work.

Answer 3

In principle I see no reason why using a proxy wouldn't work. I don't know enough about nginx to know whether that particular config would work or not.

Another option that may be worth considering is upgrading the ssl/tls library and root certificate store without upgrading the OS as a whole. Obviously this would require some level of compatibility/regression testing and would likely involve building the library in question from source.

If you can't handle modern certificates (from a >= 2048 bit root and with sha256 signatures) you are going to start having problems with pretty much any ssl service in the near future, not just paypal.

Answer 4

As ewwhite pointed out, RHEL4 has been EOL since 2012.

Why can't you upgrade? If the issue is licensing cost, there's CentOS. If the issue is some kind of code dependency, um. I don't have a glib answer for that like I do for the cost, but it's only going to get worse over time.

I'd understand if this was some legacy thing that you were required to keep around for legal compliance reasons (and kept far, far away from the internet), but this is your actual line of business you're talking about. You don't want to become a statistic. Just a reminder: Home Depot spent $43,000,000 on their data breach.

Please reconsider the "updating our servers is not an option" stance.