¿Por qué se envía el hash SHA-1 del certificado en la extensión TLS "URL del certificado del cliente"?

Question

¿Por qué se envía el hash SHA-1 del certificado en la extensión TLS "URL del certificado del cliente"?

#1 de Steffen Ullrich (2 votos)

4

Según RFC6066 , los clientes restringidos pueden enviar URL de certificado en lugar de certificados completos para la autenticación del cliente TLS:

After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message as
follows (see also Section 2):

     enum {
      individual_certs(0), pkipath(1), (255)
  } CertChainType;

  struct {
      CertChainType type;
      URLAndHash url_and_hash_list<1..2^16-1>;
  } CertificateURL;

  struct {
      opaque url<1..2^16-1>;
      unint8 padding;
      opaque SHA1Hash[20];
  } URLAndHash;

...

The hash corresponding to each URL is the SHA-1 hash of the
certificate or certificate chain (in the case of X.509 certificates,
the DER-encoded certificate or the DER-encoded PkiPath).

...

The server MUST check that the SHA-1 hash of the contents of the
object retrieved from that URL (after decoding any MIME Content-
Transfer-Encoding) matches the given hash.  If any retrieved object
does not have the correct SHA-1 hash, the server MUST abort the
handshake with a bad_certificate_hash_value(114) alert. This alert
is always fatal.

Un atacante activo puede modificar fácilmente la URL para que apunte a un certificado (o cadena de certificados) de su elección & Reemplace los 20 bytes de "SHA1Hash" con el hash SHA1 calculado correspondiente, y el servidor se dará cuenta del problema solo cuando intente verificar el mensaje de "Verificación de certificado" del cliente. Además, el servidor verifica el hash SHA1 solo después de recuperar los contenidos señalados por la URL, por lo que tampoco se evita cualquier ataque genérico como el desbordamiento del búfer o la inyección de SQL en el servidor que aloja la URL. Entonces, ¿por qué se incluye el hash SHA1 de 20 bytes de la URL en este mensaje?

tls certificates

pregunta Naruto999 12.05.2016 - 23:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates

¿Qué medio para almacenar las claves de cifrado de disco completo es fácil de usar y fácil de destruir? EU-GDPR y lo que necesito para ayudar a desarrollar un CRM alojado en una máquina virtual

score 2 · Accepted Answer

Según tengo entendido, su problema es que un hombre activo en el medio puede hacer que un servidor S acceda a una URL en el host U y esta URL la especifique el atacante. Y el problema con esto no es que el atacante pueda acceder a los contenidos detrás de esta URL (no puede), sino que el acceso a esta URL podría provocar un error en la U del servidor.

Por lo tanto, para que este ataque funcione, se deben aplicar las siguientes condiciones:

Debe haber un error en el servidor U que se puede activar simplemente accediendo a la URL específica.
El atacante puede hacer un hombre activo en el ataque central.
El atacante no quiere o no puede acceder al servidor U directamente, por lo que necesita usar el servidor S para acceder a esta URL.
El servidor S implementa la función para obtener el certificado de los clientes desde una URL.
El servidor S no filtra a qué tipo de URL puede acceder o el servidor U está permitido por este filtro.

Si todo esto se aplica, se puede usar para atacar el servidor U. Pero en la mayoría de los casos, hay formas mucho más fáciles de hacer que alguien acceda a la URL, como acceder directamente a la URL, incluyéndolo en alguna etiqueta <img src... en algún sitio web para ser accedido por otra persona o similar.

Entonces, ¿por qué se incluye el hash SHA1 de 20 bytes de la URL en este mensaje?

Si bien no encuentro ninguna explicación explícita en el RFC, supongo que es solo para asegurarse de que el servidor U realmente proporcionó el contenido esperado y no otra cosa que tenga sentido en los casos en los que el propio cliente no tiene control real sobre los cambios realizados en el servidor U. Esto no es para prohibir los ataques contra el servidor U.

Por supuesto, si el contenido servido por U no contiene el certificado de cliente esperado, se notará durante el saludo de todos modos porque la clave privada utilizada por el cliente no coincide con el certificado de cliente. Por lo tanto, es cuestionable si este hash es realmente útil o si es solo otra característica inútil que, sin embargo, se incluye en el estándar: ¿Recuerda la extensión de latido de TLS donde el servidor, sin ninguna razón real, tuvo que enviar el contenido de la carga útil de la solicitud del cliente?