Contournement de la mise à niveau Paypal

PayPal effectue des mises à niveau des certificats SSL sur tous les points de terminaison Web et API. En raison de problèmes de sécurité liés aux progrès de la puissance de calcul, l'industrie supprime progressivement les certificats SSL 1024 bits (G2) au profit de certificats 2048 bits (G5) et s'oriente vers un algorithme de cryptage de données plus puissant pour sécuriser la transmission des données, SHA -2 (256) par rapport à l'ancien standard d'algorithme SHA-1.

Cependant, nous utilisons toujours des systèmes qui ne sont pas compatibles avec les mises à niveau et la mise à jour de nos serveurs n'est pas une option. Donc, ce que nous pensons est de proxy (nginx) le point de terminaison paypal afin que paypal pense que le serveur nginx (qui prend en charge la mise à jour) frappe ce point de terminaison au lieu de nos anciens serveurs. Est-ce possible? sinon, quelles sont les options possibles pour contourner cette mise à niveau?

Voici un exemple de configuration du proxy nginx

 serveur {
    écouter 80;
    nom_serveur 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;
    }
} 

C'est moins une mise à niveau et plus une opportunité de reconstruire et de refactoriser. Depuis combien de temps ces systèmes RHEL4 sont-ils en production? 2006? 2007?

Votre organisation a-t-elle ignoré le calendrier du cycle de vie de Red Hat et les avertissements concernant la fin des périodes de support? Cela signifie-t-il que tous ces systèmes fonctionnent sans égal depuis la dernière version du package?

Pouvez-vous expliquer pourquoi vous êtes toujours sur RHEL4? Cela a vraiment pris fin en 2012. Au cours de cette période, il a été possible de simplement reconstruire.

Pour ce problème particulier, je pense que la meilleure approche consiste à évaluer l'effort de reconstruction sur un système d'exploitation plus récent. EL6 ou EL7 seraient de bons candidats et bénéficieraient d'un soutien actif.

Il est si difficile (et dans ce cas inutile) de marcher contre le vent, alors pourquoi ne le suivez-vous pas à la place? Je peux comprendre que la mise à niveau peut parfois être pénible mais ça vaut le coup.

De plus, ne pas être en mesure de travailler avec des 2048-bitcertificats vous entraînera de nombreux autres problèmes au cours des prochaines années. Je suppose que non seulement paypal, mais de nombreux autres services oublieront 1024-bitet ne pas pouvoir suivre les mises à niveau vous rendra fou pour faire fonctionner les choses.

En principe, je ne vois aucune raison pour laquelle l'utilisation d'un proxy ne fonctionnerait pas. Je ne sais pas assez sur nginx pour savoir si cette configuration particulière fonctionnerait ou non.

Une autre option qui mérite d'être envisagée est la mise à niveau de la bibliothèque ssl / tls et du magasin de certificats racine sans mettre à niveau le système d'exploitation dans son ensemble. Évidemment, cela nécessiterait un certain niveau de test de compatibilité / régression et impliquerait probablement la construction de la bibliothèque en question à partir de la source.

Si vous ne pouvez pas gérer les certificats modernes (à partir d'une racine> = 2048 bits et avec des signatures sha256), vous allez commencer à avoir des problèmes avec à peu près n'importe quel service SSL dans un avenir proche, pas seulement paypal.

Comme l'a souligné ewwhite, RHEL4 est EOL depuis 2012 .

Pourquoi ne pouvez-vous pas mettre à niveau? Si le problème est le coût des licences, il y a CentOS . Si le problème est une sorte de dépendance au code, euh. Je n'ai pas de réponse claire à cela comme je le fais pour le coût, mais cela ne fera qu'empirer avec le temps.

Je comprendrais si c'était quelque chose d'héritage que vous deviez garder pour des raisons de conformité légale (et loin, très loin d'Internet), mais c'est votre secteur d'activité réel dont vous parlez. Vous ne voulez pas devenir une statistique. Juste un rappel: Home Depot a dépensé 43 000 000 $ pour leur violation de données.

Veuillez reconsidérer la position «la mise à jour de nos serveurs n'est pas une option».