PayPal está realizando actualizaciones a los certificados SSL en todos los puntos finales web y API. Debido a las preocupaciones de seguridad sobre los avances en potencia informática, la industria está eliminando gradualmente los certificados SSL de 1024 bits (G2) a favor de los certificados de 2048 bits (G5), y se está moviendo hacia un algoritmo de cifrado de datos de mayor potencia para asegurar la transmisión de datos, SHA -2 (256) sobre el antiguo algoritmo SHA-1 estándar.
Sin embargo, todavía estamos utilizando sistemas que no son compatibles con las actualizaciones y la actualización de nuestros servidores no es una opción. Entonces, lo que pensamos es proxy (nginx) el punto final de paypal para que paypal piense que el servidor nginx (que admite la actualización) está llegando a ese punto final en lugar de nuestros servidores antiguos. es posible? Si no, ¿cuáles son las posibles opciones para evitar esta actualización?
Aquí hay una configuración de muestra del proxy nginx
servidor {
escucha 80;
nombre_servidor 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;
ubicación / nvp {
proxy_pass https://api.sandbox.paypal.com/nvp;
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header X-Fordered-For $ proxy_add_x_forwards_for;
proxy_set_header Host $ http_host;
}
}
Respuestas:
Esto es menos una actualización y más una oportunidad para reconstruir y refactorizar. ¿Cuánto tiempo llevan en producción estos sistemas RHEL4? 2006? 2007?
¿Su organización ignoró la programación del ciclo de vida de Red Hat y las advertencias sobre el final de los períodos de soporte? ¿Significa eso que todos estos sistemas se ejecutan sin igual desde el último lanzamiento del paquete?
¿Puede dar alguna razón sobre por qué todavía está en RHEL4? Eso realmente terminó al final de la vida en 2012. En ese período de tiempo, ha habido la oportunidad de simplemente reconstruir.
Para este problema en particular, creo que el mejor enfoque es medir el esfuerzo para reconstruir en un sistema operativo más actual. EL6 o EL7 serían buenos candidatos y estarían bajo un apoyo activo.
fuente
Es tan difícil (y en este caso inútil) caminar contra el viento, ¿por qué no lo sigues? Puedo entender que la actualización puede ser una molestia a veces, pero vale la pena.
Además, no poder trabajar con
2048-bitcertificados todavía lo llevará a muchos más problemas en los próximos años. Supongo que no solo PayPal, sino que muchos otros servicios se olvidarán1024-bity el no poder seguir las actualizaciones hará que te vuelvas loco para que las cosas funcionen.fuente
En principio, no veo ninguna razón por la que usar un proxy no funcione. No sé lo suficiente sobre nginx para saber si esa configuración particular funcionaría o no.
Otra opción que vale la pena considerar es actualizar la biblioteca ssl / tls y el almacén de certificados raíz sin actualizar el sistema operativo en su conjunto. Obviamente, esto requeriría cierto nivel de pruebas de compatibilidad / regresión y probablemente implicaría construir la biblioteca en cuestión desde la fuente.
Si no puede manejar certificados modernos (desde una raíz de> = 2048 bits y con firmas sha256) comenzará a tener problemas con casi cualquier servicio SSL en el futuro cercano, no solo con PayPal.
fuente
Como señaló ewwhite, RHEL4 ha sido EOL desde 2012 .
¿Por qué no puedes actualizar?
Si el problema es el costo de la licencia, hay CentOS. Si el problema es algún tipo de dependencia de código, um. No tengo una respuesta simplista para eso como lo hago por el costo, pero solo empeorará con el tiempo.Entiendo que si se trata de algo heredado que se le exigió que mantuviera por razones de cumplimiento legal (y que se mantuviera lejos, muy lejos de Internet), pero esta es su línea de negocios real de la que está hablando. No quieres convertirte en una estadística. Solo un recordatorio: Home Depot gastó $ 43,000,000 en su violación de datos.
Reconsidere la postura "actualizar nuestros servidores no es una opción".
fuente