¿El certificado del lado del cliente robado es una preocupación válida para la comunicación SSL? ¿Cómo construir un sistema de revocación automático?

Question

¿El certificado del lado del cliente robado es una preocupación válida para la comunicación SSL? ¿Cómo construir un sistema de revocación automático?

#1 de sebastian nielsen (1 votos)

0

En el contexto de la comunicación de servidor a servidor, hacemos TLS / SSL con autenticación de certificado de cliente. Entonces la comunicación se parece a la siguiente:

service_a on Host_A (as the SSL client) --> service_b on Host_B (as the SSL server)

Tenemos nuestra propia infraestructura PKI y CA organizativa para emitir los certificados para service_a y service_b.

Supongamos que Host_A quedó comprometido (por lo tanto, es una clave privada y el certificado de service_a fue robado por el atacante). Este atacante configura silenciosamente otro EC2 VM Host_C y ejecuta el servicio (modificado maliciosamente) en Host_C (nota: la clave privada de Host_A también está disponible aquí en Host_C)

¿Cómo puede el servicio_b (junto con nuestra propia infraestructura PKI y CA) proteger o responder automáticamente a este escenario? ¿Hay alguna manera de diseñar un sistema de este tipo?

public-key-infrastructure key-management tls certificate-authority certificate-revocation

pregunta chen 28.07.2016 - 20:10

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure key-management tls certificate-authority certificate-revocation

¿El uso de dispositivos múltiples y los robots en Telegram son una excusa para solo la encriptación SSL? ¿Es posible que nuestro administrador de seguridad aún vea nuestros paquetes desde el lado del servidor?

score 1 · Answer 1

Hay muchas formas de detectar este escenario.

1: puede detectar el inicio de sesión doble ya que Host_A y Host_C se iniciarían al mismo tiempo, a menos que el atacante impida de alguna manera que Host_A acceda a Host_B.

2: puede utilizar la IP del host para detectar si la IP del cliente cambia repentinamente. Supongo que desea tener un cliente de API que se comunique con un punto final de API en Host_B y, por lo tanto, la IP del cliente debería ser estática.

3: puede "hacer una huella" del cliente API, y si el cliente API se comporta de manera diferente (otro agente del usuario o está enviando diferentes encabezados), se considera un compromiso.

Puede haber otro signo de manipulación, donde puedes detectar algo que no es normal. Supongamos que su cliente API original toma un tiempo fijo para realizar operaciones específicas. Luego, puede cronometrar estas acciones y si el cliente API realiza la acción más rápido o más lento, puede ser un signo de ataque.

Ahora a la acción. Para facilitar una revocación más rápida, sugeriría, además de revocar a través de CRL. Como su servidor puede saber qué certificado es robado, puede configurar su servicio de API para que no acepte inicios de sesión con ese certificado SSL, de hecho, una "revocación por software". Esto significa que el certificado se bloquea de inmediato, en lugar de tener que esperar a que el servidor SSL vuelva a leer y analizar una CRL en el sistema SSL.