TLS: potrebbe la sessione ripresa e la sessione originale nella stessa connessione?

1

In tls 1.2, sappiamo che ogni connessione è associata a una sessione, e la ripresa della sessione può essere usata per stabilire rapidamente una nuova connessione usando l'ID di sessione della sessione originale di una vecchia connessione, per di più, la sessione ripresa non è una nuova sessione.    Tuttavia, se è vero che esiste una sola sessione in una connessione, perché TLS può rinegoziare all'interno di una connessione esistente per creare una nuova sessione e possiamo usare la ripresa della sessione per aggiornare le chiavi in una connessione esistente poiché la sessione ripresa non è una nuova sessione?

    
posta xinyu 08.06.2015 - 14:54
fonte

1 risposta

0

Non ci sono problemi nell'avere più sessioni su una singola connessione - ovviamente non simultaneamente, ma se, all'interno di una connessione, viene eseguita una nuova stretta di mano (una "rinegoziazione"), allora quella nuova stretta di mano può riprendere una sessione esistente , incluso quello che era attivo prima di quella nuova stretta di mano. Come per ogni ripresa di sessione, funziona solo se sia il client che il server sono d'accordo, e ricorda i parametri della sessione in qualche modo (se ticket di sessione vengono utilizzati, la memoria del server può essere effettivamente scaricata sul client.

Tuttavia, ciò solleva la questione del perché si dovrebbe rinegoziare, se questo è solo per mantenere la sessione corrente in esecuzione. Un caso comune di rinegoziazione è quando IIS (server Web di Microsoft) è configurato per utilizzare l'autenticazione client basata su certificato. IIS, per impostazione predefinita, utilizza i certificati client su una base per directory, non per l'intero server; quindi, le cose vanno normalmente come segue:

  • Il client si connette al server. Viene eseguito un "normale" handshake, senza richiesta di un certificato client.
  • Una volta completata l'handshake, il client invia la richiesta HTTP. A quel punto , il server impara il percorso di destinazione esatto per la richiesta (fino a quel momento il server sapeva, nel migliore dei casi, il nome del server desiderato, tramite estensione SNI , ma non il percorso completo).
  • Se il percorso di destinazione è configurato per utilizzare i certificati client, il server bufferizza la richiesta e avvia un nuovo handshake ( HelloRequest e così via).
  • Il client risponde con ClientHello e normalmente tenta di riprendere la sessione in corso. Tuttavia, il server si rifiuta e avvia una nuova sessione. Questo perché l'intero punto (in quella situazione) di iniziare una nuova stretta di mano è chiedere un certificato client, e questo può accadere solo con una stretta di mano completa, cioè con una nuova sessione.
  • Una volta che il nuovo handshake è completato e il client autenticato, la richiesta memorizzata viene elaborata (questo è sicuro finché client e server implementano opzione sicura di rinegoziazione , che è stata progettata esattamente per tale utilizzo).

Il punto che sto facendo qui è che il client cerca davvero di riprendere la stessa sessione, come consentito dagli standard, e il server rifiuta la ripresa perché ha innescato un nuovo handshake proprio per consentire l'apertura di una nuova sessione. In pratica, eseguire una nuova stretta di mano ma riprendere la stessa sessione può essere fatto da persone che sentono di dover "rinnovare le chiavi" per una ragione non giustificata; siamo più nel dominio della Tradizione che della Scienza qui. Concettualmente, fare una nuova stretta di mano con la stessa sessione potrebbe essere usato come un modo per scambiare alcune nuove estensioni TLS, ma attualmente non ci sono praticamente estensioni definite per le quali una cosa del genere abbia senso (ma le estensioni sono, per definizione, aperte, quindi questo può essere utile un giorno).

    
risposta data 08.06.2015 - 16:12
fonte

Leggi altre domande sui tag