16

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;
    }
} 
  • 62
    You've put off these upgrades far too long already. At this point upgrading the servers is the only option you should be considering. Simply having those things in production at all is sufficient to fail a proper security audit. – Michael Hampton Apr 28 '16 at 6:56
  • 34
    " and updating our servers is not an option." -- I'm sure it might be difficult, but it really needs to become an option. There comes a point in any system's lifecycle when you need to move it forwards and you've gone well past that here. – Rob Moir Apr 28 '16 at 7:11
  • 19
    "updating our servers is not an option". Why is updating not an option? Do you have legacy code that uses a quirk of RHEL4? Does your software have a plugin that's no longer supported on RHEL 6 or 7? – Nzall Apr 28 '16 at 7:44
  • 26
    I'm going to echo the chorus here. Figure out why upgrading isn't an option, fix that, then upgrade. Paypal isn't doing this just because they're feeling like dicks. – Shadur Apr 28 '16 at 7:58
  • 32
    As a security-conscious and computer-literate person, if I was your client and found out you did what you are attempting to do I would immediately stop working with your company and would very likely never purchase anything from your company again. – Shaamaan Apr 28 '16 at 9:08
75

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.

  • 32
    This. If your systems are so old that they can't be upgraded they're definitely so old that they can't possibly be trusted to be secure anymore. – Shadur Apr 28 '16 at 7:59
20

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.

  • 13
    Windows and iOS, chrome, Mozilla, all are not accepting SHA1 certs after 1/1/2017. So it will be a short fix for PayPal only. Only thing I could imagine are expensive to replace are things like PIN-terminals for credit card payment or so. – TJJ Apr 28 '16 at 8:24
  • 5
    It will be even more "expensive" when customers leave you... – sysfiend Apr 29 '16 at 12:33
11

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.

  • 3
    Neither RHEL 4 nor RHEL 5 will handle modern SHA-2 certificates. – Michael Hampton Apr 29 '16 at 5:17
9

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.

  • 5
    RHEL licenses are not version locked. If you're paying for RHEL 4, you can upgrade all the way to RHEL 7 (current) on the same entitlement. – Michael Hampton Apr 30 '16 at 0:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.