Cliente que requiere nuestra clave privada SSL para configurar el equilibrador de carga que llega a nuestro servidor. ¿Tiene sentido?

5

Estoy enfrentando una situación inusual, espero que puedas aclararme esto.

Administramos algunas aplicaciones que son accesibles a través de solicitudes HTTPS en el puerto 443 de nuestro servidor X.

Tenemos un nuevo cliente que también se supone que nos llegará a través de nuestro puerto 443 en el servidor X. Sin embargo, el cliente va a usar algún tipo de Load Balancer (proxy + snat según ellos) para hacer eso.

Para que el Load Balancer pueda conectarse con nosotros, el cliente requiere nuestro par de Certificado Público + Clave Privada , de lo contrario, el Load Balancer restablecería las conexiones con nosotros debido a la falta de coincidencia de los pares de claves.

Esto es completamente absurdo para mí, ya que lo privado debería ser simplemente privado, no puedo compartirlo. Es contra toda política de seguridad que conozco.

Lo curioso es que proporcionaron cierta documentación que parece indicar exactamente esto. Este es el enlace:

enlace

Parece que usan alguna tecnología llamada Big IP y requiere la clave privada de acuerdo con esta declaración en el enlace anterior:

Acciones recomendadas Puede corregir este error configurando los perfiles SSL afectados con el par de claves de certificado que presenta el servidor de destino . Para ello, realice los siguientes procedimientos ...

¿Alguien con quien te enfrentaste a una situación similar a esta?

Incluso su tecnología realmente lo requiere, no tengo conocimiento de ninguna "API" proporcionada por HTTPS que pueda manejar el tráfico previamente cifrado por un equilibrador de carga, por lo que estoy bastante confundido.

Todo tipo de aclaración es útil. Gracias a todos.

    
pregunta vinicius.olifer 21.07.2017 - 15:57
fuente

1 respuesta

5

Parece que están usando la capacidad Proxy SSL de F5, lo que significa que el dispositivo F5 no es el cliente de su aplicación (no está terminando en el dispositivo, sino que pasa) pero en cambio les da la posibilidad de descifrar el el tráfico para determinar si se puede almacenar en caché y volver a utilizar para mejorar el rendimiento. Por ejemplo, si pueden almacenar en caché algunas cosas en su borde, pueden devolvérselas a sus usuarios sin tener que realizar viajes completos de ida y vuelta a los servidores de origen. Si no pueden descifrar el tráfico, no pueden almacenarlo en caché.

Esto, como usted sabe claramente, tiene implicaciones de seguridad. Si insisten en esta arquitectura, y los datos y los riesgos son solo suyos, entonces necesita un certificado específico para su aplicación que no se comparta para proteger los datos de cualquiera de sus otros clientes. Luego puede instalar el certificado en los servidores de aplicaciones que tiene para ellos, y ellos pueden instalarlo en su F5, y siempre que no sea una oportunidad para que el certificado se use accidentalmente para sus otros clientes, entonces hay muy poco riesgo para tú.

SI , sin embargo, su aplicación no está diseñada para permitir que se separen de esa manera, y el certificado no se puede aislar solo para su uso, entonces En mi opinión, debes declinar. No puede darles una clave que les permita acceder a los datos de otros clientes bajo ninguna circunstancia.

    
respondido por el Xander 21.07.2017 - 16:35
fuente

Lea otras preguntas en las etiquetas