Perché l'hash SHA-1 del certificato è stato inviato nell'estensione TLS "URL certificato client"?

Question

Perché l'hash SHA-1 del certificato è stato inviato nell'estensione TLS "URL certificato client"?

#1 da (2 voti)

4

In base a RFC6066 , i client vincolati possono inviare URL di certificati anziché certificati completi per l'autenticazione del client 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 utente malintenzionato attivo può facilmente modificare l'URL in modo che punti a un certificato (o catena di certificati) di sua scelta e amp; sostituire i 20 byte di "SHA1Hash" con il corrispondente hash SHA1 corrispondente e il server realizzerà il problema solo quando tenta di verificare il messaggio "Verifica certificato" dal client. Inoltre, il server verifica l'hash SHA1 solo dopo aver recuperato il contenuto indicato dall'URL, quindi non viene impedito alcun attacco generico come buffer overflow o SQL injection sul server che ospita l'URL. Quindi, perché l'hash SHA1 da 20 byte dell'URL incluso con questo messaggio?

tls certificates

posta Naruto999 12.05.2016 - 23:15

fonte

1 risposta

Leggi altre domande sui tag tls certificates

Perché un utente malintenzionato include un corpo di richiesta con una richiesta HTTP GET? Perché CVSSv2 non considera XSS un impatto di riservatezza?

score 2 · Accepted Answer

Da quanto ho capito il tuo problema è che un uomo attivo nel mezzo può fare in modo che un server S acceda a un URL nell'host U e questo URL sia specificato dall'attaccante. E il problema con questo non è che l'autore dell'attacco possa accedere ai contenuti dietro questo URL (non può) ma che solo l'accesso a questo URL potrebbe innescare un bug sul server U.

Per far sì che questo attacco funzioni, devono essere applicate le seguenti condizioni:

Ci deve essere un bug nel server U che può essere attivato semplicemente accedendo all'URL specifico.
L'attaccante può fare un uomo attivo nell'attacco centrale.
L'autore dell'attacco non è disposto o non è in grado di accedere direttamente al server U, quindi deve utilizzare il server S per accedere a questo URL.
Il server S implementa la funzione per ottenere il certificato dei client da un URL.
Il server S non filtra quale tipo di URL può accedere o il server U è consentito da questo filtro.

Se tutto questo si applica può essere usato per attaccare il server U. Ma nella maggior parte dei casi ci sono modi molto più semplici per rendere qualcuno l'accesso ad URL, come accedere direttamente all'URL, includendolo in qualche tag <img src... su qualche sito web per essere accessibili da qualcun altro o simili.

Then, why is 20-byte SHA1 hash of URL included with this message?

Anche se non trovo alcuna spiegazione esplicita nella RFC, la mia ipotesi è che sia solo per assicurarsi che il server U abbia effettivamente fornito il contenuto previsto e non qualcos'altro che abbia un po 'senso nei casi in cui il client stesso non ha controllo reale sulle modifiche eseguite sul server U. Questo non impedisce gli attacchi contro il server U.

Ovviamente se il contenuto servito da U non contiene il certificato del client atteso, lo si noterà comunque durante l'handshake perché la chiave privata utilizzata dal client non corrisponde al certificato del client. Quindi è discutibile se questo hash è veramente utile o se è solo un'altra caratteristica inutile che tuttavia è stata introdotta nello standard: Ricorda l'estensione heartbeat TLS in cui il server per nessun motivo reale ha dovuto inviare il contenuto del carico utile della richiesta dei client indietro?