Apache Tomcat ha la capacità di utilizzare l'ID sessione TLS invece di un cookie di sessione o JSESSIONID nella querystring. Il mio sito è HTTPS Ovunque.
Questo sembra utile in quanto non devo preoccuparmi del furto dei cookie di sessione, e posso usare sessioni per i programmi utente che non fanno i cookie.
Sono immune a Session Hijacking / Session Fixation qui?
Qualche altro problema di cui preoccuparsi?
Gli ID di sessione SSL sono in chiaro e visibili a chiunque stia guardando i bit attraverso la rete. Se sei preoccupato per il dirottamento, questa non sarebbe una buona idea.
Ti sto dicendo che ti stai riferendo all'ID sessione TLS come specificato in RFC 4507
No, non penso che questo ti darà ciò di cui hai bisogno. L'ID sessione TLS è un ticket fornito dal server al client che consentirà al client di riprendere una sessione in un secondo momento (vale a dire dopo che la sessione esistente è cessata). Questo è focalizzato sul livello TLS, che puoi considerare come un livello sotto il livello dell'applicazione. Il livello TLS consiste nello stabilire la connessione sicura e non sa nulla del tuo livello di applicazione.
Quando ti connetti per la prima volta a un servizio abilitato TLS, c'è una procedura di handshake tra il server e il client che viene utilizzata per stabilire la connessione sicura. Con l'uso dell'ID di sessione, il processo di handshake può essere ridotto nelle connessioni successive: fornendo un ID di sessione valido, il client sta essenzialmente dicendo "Ehi, riagganciamo e usiamo le stesse chiavi di crittografia ecc. Che abbiamo usato l'ultima volta. Il server potrebbe dire "Hey cool, lascia andare" o potrebbe dire "Scusate, è stato troppo lungo, dobbiamo rinegoziare".
Poiché questo è un livello sotto l'applicazione, l'ID della sessione TLS non sa se sei autenticato con l'applicazione o qual è il tuo livello di autorizzazione. Normalmente, ciò si verifica solo dopo che la connessione TLS è stata negoziata e stabilita. Non è possibile aggiungere queste informazioni all'ID di sessione TLS poiché si tratta di un valore crittografato generato dal livello TLS lato server. Ciò significa anche che l'applicazione non può determinare le credenziali dell'utente dall'ID di sessione TLS.
Se i tuoi utenti devono essere autenticati e autorizzati, devi davvero gestirlo in una sessione o un cookie a livello di applicazione, devi essere in grado di verificare che non sia stato modificato e devi includere protezione aggiuntiva, come Token di protezione CSRF ed è necessario verificare tutto questo su ogni richiesta.
Leggi altre domande sui tag web-application tls session-management