HTTPS e cookie crittografato per la sessione

È corretto che di solito nell'accedere al sito Web crittografato con ssl non sia necessario normalmente crittografare i cookie, ma si tratta anche se qualcuno in qualche modo ha dirottato la tua connessione ssl, il TGT dovrebbe essere inutilizzabile per quella persona.

Come negli scenari SSO, le cose cambiano molto.

Processo di autenticazione / Flusso di richieste

Durante il processo di autenticazione dopo che la tua identità è stata verificata da KDC (centro di distribuzione delle chiavi), Authentication Server ti invia due messaggi.

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address 
    lifetime of the TGT 
    TGS Session Key,
    and is encrypted with the TGS Secret Key . 

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGS Session Key è la chiave condivisa che verrà utilizzata tra te e il TGS.  nel passaggio successivo

La chiave segreta del tuo cliente viene determinata richiedendo la tua password, aggiungendo un salato e eseguendo l'hashing dell'intero processo. puoi usarlo per decifrare il secondo messaggio per ottenere la chiave di sessione TGS.
Tuttavia, non è possibile decodificare il TGT poiché non si conosce la chiave segreta TGS. Il TGT crittografato è memorizzato nella cache delle credenziali.

Ora hai la chiave di sessione TGS, puoi richiedere il token finale per accedere al servizio richiesto da TGS

Il TGT (crittografato con la chiave segreta TGS) e per la richiesta di servizio HTTP di esempio (crittografato con la chiave di sessione TGS) viene inviato al TGS

TGS ora decodifica il TGT e recupera la chiave di sessione TGS, con questa chiave decrittografa la richiesta di autenticazione http

Il Ticket Granting Server genera quindi in modo casuale la chiave di sessione del servizio HTTP e prepara il ticket del servizio HTTP che contiene:

your name/ID,
HTTP Service name/ID,
your network address 
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

Quindi il TGS ti manda due messaggi. Uno è il ticket di servizio HTTP crittografato; l'altro contiene:

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

fino a ricevere il messaggio client decodifica il secondo messaggio e ottiene la chiave di sessione http

Ora l'utente ha accesso al servizio HTTP

Che cosa succede se TGT non è stato crittografato

Se TGT non è stato crittografato, chiunque lo abbia può alterare la richiesta del servizio HTTP creando l'identità di qualcuno nella richiesta e ottenendo la chiave di sessione del servizio HTTP

Anche un utente può sfruttare il processo di autenticazione in ogni caso modificando il TGT

quindi per evitare l'uso improprio della crittografia TGT è fatto

I cookie rimangono nel browser. E se hanno alcune informazioni sensibili memorizzate, dovrebbero essere crittografate. Anche se sosterrò che qualsiasi informazione sensibile non dovrebbe essere memorizzata nei cookie.
E l'ID della sessione di crittografia (che è già un valore casuale) non ha alcun senso. E se stai usando alcune informazioni utente come ID di sessione, allora questa pratica è di per sè cattiva e invece di crittografare, dovresti pensare a ridefinire come viene gestita una sessione. Controlla OWASP per questo.

Se il tuo cookie è solo un ID di sessione che consente al server di identificarti, la crittografia è, come si commenta correttamente, inutile oltre alla crittografia TLS. Tuttavia, potrebbero esserci applicazioni che hanno realmente bisogno di memorizzare informazioni in un cookie che desiderano mantenere riservate, anche riservate dagli utenti che ispezionano i propri cookie con gli strumenti di sviluppo nel browser. Un esempio potrebbe essere una sessione di informazioni per un ambiente distribuito in cui i server non condividono un singolo database e il cookie contiene per es. un identificatore confidenziale del server di emissione che non vuoi che l'utente veda perché potrebbe volerlo falsificare (ovviamente si tratta di pura speculazione).

Cercherei sempre di evitare un simile progetto e di adottare uno standard aperto come SAML, ma sono abbastanza sicuro che ci siano applicazioni che lo fanno in questo modo.