¿Se puede interceptar una conexión TLS implementada correctamente?

2

Suponiendo una conexión TLS en la que tanto el servidor como el cliente se adhieren perfectamente a los estándares pertinentes.

  1. ¿Puede un proxy HTTPS transparente interceptar la conexión TLS? (Suponiendo que el certificado "simulacro de CA" usado por el proxy esté en Trusted Root en el cliente)

  2. (¿Posiblemente fuera de alcance, no estoy seguro?) Si no, ¿cuál (a) servidor y (b) navegador están más cerca de tener dicha implementación?

Esta pregunta es provocada por la siguiente cita con respecto al protocolo TLS y al software de proxy Squid "Si la seguridad de [TLS] se estaba usando correctamente, no es posible utilizar la interceptación [también conocida como intercepción como se describe en la P1]. Hay un número creciente de transacciones que lo hacen de una manera cada vez más cercana a ese uso adecuado. "

    
pregunta o.comp 04.09.2015 - 00:02
fuente

2 respuestas

1
  

¿Puede un proxy HTTPS transparente interceptar la conexión TLS? (Suponiendo que el certificado "simulacro de CA" usado por el proxy esté en Trusted Root en el cliente)

La interceptación de HTTPS con un proxy (transparente) es teóricamente posible si se cumplen todas las condiciones siguientes:

  • La CA de interceptores es de confianza (como espera).
  • No se realiza el anclaje del certificado o las claves públicas. Los navegadores son conscientes de la interceptación legal de SSL, es decir, el cambio de anclaje si el certificado fue firmado por una CA que se agregó manualmente (y de confianza). Pero las aplicaciones como Dropbox no son conscientes de esta situación y fallarán.
  • No se utilizan certificados de cliente. El uso de certificados de cliente necesita un TLS de extremo a extremo real, es decir, no puede ser interceptado incluso por una CA de confianza. O, al menos, el certificado de cliente original no se puede reenviar al servidor original, lo que hace que la autenticación mutua falle si el servidor verifica el certificado de cliente correctamente.
  

(¿Posiblemente fuera de alcance, no estoy seguro?) Si no, ¿cuál (a) servidor y (b) navegador están más cerca de tener tal implementación?

La implementación del servidor no es relevante. La implementación del navegador solo es relevante para el comportamiento especial con el pin que describí anteriormente. Al menos Firefox y Chrome muestran este comportamiento especial.

  

Esta pregunta es provocada por la siguiente cita ...

Está tomando esta cita sin mostrar su origen y fuera de contexto. Buscar en Google muestra que solo es una cita de un correo en la lista de correo de squid y no forma parte de Cualquier documentación. También tiene un prefijo con la frase "Aunque tenga en cuenta que ssl-bump es un ataque MITM a un protocolo de seguridad", lo que sugiere que el autor significa la intercepción SSL sin el consentimiento de la aplicación, es decir, no es el caso cuando un navegador confía explícitamente en la interceptación CALIFORNIA.

    
respondido por el Steffen Ullrich 04.09.2015 - 04:47
fuente
2

Con respecto a su primera pregunta: la respuesta depende de la definición de "transparente". Para mí, la intercepción transparente implicaría que los clientes no deben agregar manualmente certificados o autoridades de certificación al "almacén de confianza" de sus dispositivos. Mientras esta condición se mantenga y su navegador compruebe correctamente la validez del certificado presentado , un atacante no podrá interceptar su conexión, a menos que logren hacer una de las siguientes acciones:

  • comprometa una de las CA en las que su dispositivo confía
  • de alguna manera obtener una CA de confianza para firmar un certificado falsificado para un sitio que en realidad no posee
  • manipular el almacén de confianza en su dispositivo
  • o tome posesión de la clave privada de un servidor específico.

La razón por la que estos son los únicos vectores de ataque (de nuevo, si la verificación de validez se implementa correctamente en el lado del cliente) es que el servidor presentará un certificado (incluida la clave pública del servidor) que está firmado con la clave privada de alguna CA . El cliente verifica si la firma coincide con la clave pública que ha almacenado para la CA correspondiente, y si lo hace, inicia un protocolo de enlace TLS / SSL con el servidor. Es en un punto de este protocolo de protocolo de enlace que el cliente cifra cierta información específica de la conexión con la clave pública del servidor. Quienquiera que esté interceptando el mensaje tendrá que descifrar la información con la clave privada del servidor y enviarla de vuelta para demostrar que no es, de hecho, otra persona.

Con respecto a su segunda pregunta, no sé qué significa exactamente en la oración que citó. Lo que sé es que todos los navegadores modernos populares validan correctamente los certificados. Sin embargo, existe otro mecanismo interesante con respecto a la seguridad de los certificados que no ha adoptado todos los navegadores modernos, al menos hasta donde sé. Fijación de clave pública es un concepto relacionado con confianza en el primer uso : cuando visita un sitio web por primera vez, "fija" la clave pública que se le mostró en ese dominio y verifica si sigue siendo el mismo en visitas posteriores a la página. Esto protege contra los escenarios de ataque 1 y 2 descritos anteriormente: ya no tiene que preocuparse por la emisión de certificados falsos si solo vio el certificado legítimo una vez antes. La fijación de claves públicas no solo se puede realizar para servidores específicos, sino también para cualquier CA en la cadena de confianza. Para responder a su pregunta real, Chrome y Firefox pueden hacer la fijación de claves públicas (y probablemente hay otras, pero no conozco a cada una de ellas).

    
respondido por el zinfandel 04.09.2015 - 01:19
fuente

Lea otras preguntas en las etiquetas