Ignorar a atualização do Paypal

O PayPal está atualizando os certificados SSL em todos os pontos de extremidade da Web e da API. Devido a preocupações de segurança com relação aos avanços no poder de computação, o setor está eliminando os certificados SSL de 1024 bits (G2) em favor dos certificados de 2048 bits (G5) e está adotando um algoritmo de criptografia de dados de maior resistência para garantir a transmissão de dados, SHA -2 (256) sobre o padrão antigo do algoritmo SHA-1.

No entanto, ainda estamos usando sistemas que não são compatíveis com as atualizações e atualizar nossos servidores não é uma opção. Portanto, o que pensamos é fazer proxy (nginx) do terminal paypal para que o paypal pense que o servidor nginx (que suporta a atualização) está atingindo esse terminal em vez de nossos servidores antigos. Isso é possível? Caso contrário, quais são as opções possíveis para ignorar esta atualização?

Aqui está um exemplo de configuração do proxy nginx

 servidor {
    ouça 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;
    }
} 

Isso é menos uma atualização e mais uma oportunidade de reconstruir e refatorar. Há quanto tempo esses sistemas RHEL4 estão em produção? 2006? 2007?

Sua organização ignorou a agenda do ciclo de vida da Red Hat e os avisos sobre o final dos períodos de suporte? Isso significa que todos esses sistemas estão funcionando sem igual desde o lançamento do último pacote?

Você pode dar algum motivo para continuar no RHEL4? Isso realmente acabou no fim da vida em 2012. Nesse período, houve uma oportunidade de simplesmente reconstruir.

Para esse problema em particular, acho que a melhor abordagem é avaliar o esforço de reconstrução em um sistema operacional mais atual. EL6 ou EL7 seriam bons candidatos e cairiam sob apoio ativo.

É tão difícil (e neste caso inútil) andar contra o vento, por que você não o segue? Eu posso entender que atualizar pode ser um pé no saco às vezes, mas vale a pena.

Além disso, a impossibilidade de trabalhar com 2048-bitcertificados ainda o levará a muitos outros problemas nos próximos anos. Eu acho que não apenas o paypal, mas muitos outros serviços esquecerão 1024-bite não poder acompanhar as atualizações levará você a ficar louco para fazer as coisas funcionarem.

Em princípio, não vejo razão para o uso de um proxy não funcionar. Não sei o suficiente sobre o nginx para saber se essa configuração específica funcionaria ou não.

Outra opção que pode ser considerada é atualizar a biblioteca ssl / tls e o armazenamento de certificados raiz sem atualizar o sistema operacional como um todo. Obviamente, isso exigiria algum nível de compatibilidade / teste de regressão e provavelmente envolveria a construção da biblioteca em questão a partir da fonte.

Se você não conseguir lidar com certificados modernos (a partir de uma raiz> = 2048 bits e com assinaturas sha256), começará a ter problemas com praticamente qualquer serviço SSL no futuro próximo, não apenas com o paypal.

Como ewwhite apontou, o RHEL4 é EOL desde 2012 .

Por que você não pode atualizar? Se o problema é o custo de licenciamento, existe o CentOS . Se o problema for algum tipo de dependência de código, hum. Não tenho uma resposta simplista para isso, como faço para o custo, mas só vai piorar com o tempo.

Eu entenderia se isso era algo legado que você precisava manter por motivos de conformidade legal (e mantido longe, muito longe da Internet), mas essa é sua linha de negócios que você está falando. Você não quer se tornar uma estatística. Apenas um lembrete: a Home Depot gastou US $ 43.000.000 em sua violação de dados.

Por favor, reconsidere a posição "atualizar nossos servidores não é uma opção".