Una terza parte può convalidare l'origine di una sessione HTTPS?

1

Mi chiedo se HTTPS può essere utilizzato come prova che un server ha segnalato una risposta.

Se ho capito bene, l'handshake iniziale è per HTTPS è l'unica volta che viene utilizzata la chiave pubblica / privata del server. Dopo questo punto viene utilizzata una chiave simmetrica, quindi i dati passati non sono firmati dall'origine, ma solo crittografati. È corretto? In tal caso, c'è comunque la possibilità di ottenere firme da siti arbitrari, visto che supportano HTTPS?

Se come cliente registro l'intera sessione HTTPS, posso provare a una terza parte che i dati che ho ricevuto sono stati effettivamente inviati dal server?

    
posta Steve Ellis 05.05.2016 - 22:38
fonte

1 risposta

4

Forse, a volte.

Ciò che viene scambiato nell'handshake iniziale non è solo una chiave simmetrica, ma piuttosto una "chiave master" per la sessione da cui le implementazioni client e server della suite di crittografia selezionata possono estrarre le chiavi per vari scopi.

Una suite di cifratura è divisa in un numero di algoritmi per diverse funzionalità:

  • Scambio chiavi
  • Crittografia collettiva
  • Autenticità del messaggio

Ad esempio, TLS_DHE_RSA_AES_256_CBC_SHA256 utilizzerà Diffie-Hellman effimero e RSA per lo scambio di chiavi, AES-256 per la crittografia di massa e HMAC-SHA256 per l'autenticità del messaggio.

Quando lo scambio di chiavi avviene all'inizio, la chiave RSA a lungo termine del certificato viene utilizzata per firmare i parametri di scambio chiave Diffie-Hellman. Lo scambio della chiave DH viene utilizzato per concordare una chiave master. La chiave master viene quindi utilizzata per derivare altre chiavi, tra cui 256 bit per la chiave AES (chiave di crittografia) e un numero di bit per la chiave di autenticazione (utilizzata in HMAC-SHA256, in questo caso).

Ogni record viene autenticato utilizzando l'algoritmo di autenticazione definito nella suite di crittografia. Di solito, questo è un hash HMAC.

Ora, per dimostrare che i dati sono stati ricevuti dopo il fatto , ci sono due casi:

  • Se viene utilizzato uno scambio di chiavi non effimero (ad es. scambio di chiavi RSA, non DHE o ECDHE), il traffico acquisito può essere interamente ripristinato, inclusa la validità degli hash di autenticazione, data la chiave privata del certificato del server.
  • Se viene utilizzato uno scambio di chiavi temporaneo, anche se si ottiene la chiave a lungo termine (chiave privata del server) dopo che si è verificata una connessione, non è possibile recuperare la chiave master e, pertanto, non è possibile recuperare i messaggi o dimostrare la validità dei messaggi. Ciò è dovuto a una proprietà nota come "inoltro segreto", che deriva dal fatto che gli elementi privati dello scambio di chiavi sono generati specificamente per quella sessione e vengono scartati al termine dello scambio di chiavi.

Se, al momento della connessione, decidi che fai vuoi provare il contenuto in un secondo momento, potresti salvare la chiave master della sessione da qualche parte. Dando questa chiave alla terza parte che ha catturato la conversazione, è possibile mostrare loro il contenuto e sarebbero in grado di vedere che i record di autenticità erano validi.

    
risposta data 05.05.2016 - 23:01
fonte