(corretto) modo di informare il server TLS per rilasciare la sessione TLS con clientAuth

5

C'è un modo per un client TLS di informare il server che non intende più riprendere le sue sessioni autenticate?

Esempio:

Un client ha stabilito una sessione autenticata con il server che fornisce il suo certificato con l'utilizzo della chiave clientAuth, quindi ha eseguito tutto il lavoro a livello di applicazione e ora desidera dire al server qualcosa del tipo:

Non è più necessario mantenere la mia sessione autenticata; la prossima volta vedrai questo sessionID su un client ciao - non riprendere la sessione, perché ho finito il mio lavoro qui

C'è un modo per dirlo? Per quanto vedo, close_notify alert non significa questo, informa solo che la connessione verrà chiusa o che i dati non protetti verranno trasferiti attraverso di essa.

    
posta Trueblacker 02.09.2015 - 11:08
fonte

1 risposta

3

Is there a way for a TLS client to inform the server that it doesn't intend to resume its authenticated session(s) anymore?

Sì, inviando un avviso con una gravità fatale.

Da RFC 5077 :

5.1. Invalidating Sessions

The TLS specification requires that TLS sessions be invalidated when errors occur.

Questo è un riferimento apparente * al seguente testo da RFC 5246 (enfasi mia):

7.2. Alert Protocol

One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections.

In pratica, scegliere di terminare la sessione SSL con un avviso fatale anziché con un avviso di close_notify probabilmente non causerà nulla di peggio di una voce di registro sul server. Poiché non si sta chiudendo fino a quando non è stato concluso lo scambio di dati, è improbabile che l'avviso fatale possa influire su di esso. È l'equivalente morale di terminare una connessione TCP con un RST invece di un FIN.

(Penso che in realtà puoi solo inviare un avviso close_notify con severità Fatal invece di severità di avviso, ma vorrei testarlo prima sul filo).

Ovviamente, se hai un controllo sufficiente sul tuo client per influenzare il modo in cui chiude la sessione, hai il controllo sufficiente per non inviare gli ID Sessione precedenti sulle connessioni successive, che raggiungeranno lo stesso obiettivo. Il server non tenterà mai di riprendere una sessione a meno che il client non abbia prima proposto quell'ID sessione. Ma se invece sei preoccupato per le terze parti che in qualche modo ottengono e riutilizzano il tuo ID sessione, l'attivazione del server per eliminarla potrebbe essere ragionevole.

* Quando dico 5077 (gennaio 2008) fa riferimento a 5246 (agosto 2008), faceva veramente riferimento a una versione precedente della specifica TLS; Sto solo trascinando le specifiche più recenti per te da guardare. In effetti, la lingua per "7.2 Alert Protocol" è equivalente per TLS 1.1 (RFC 4346) e TLS 1.0 (RFC 2246) .

    
risposta data 02.09.2015 - 14:49
fonte

Leggi altre domande sui tag