'Ripresa sessione SSL con ID sessione memorizzata nella cache'

Sì, è sicuro che la maggior parte delle implementazioni lo fanno correttamente e il metodo non è imperfetto. Tuttavia, è più probabile che tu raggiunga un punto in cui si verificherà una rinegoziazione e ci sono numero di vulnerabilità in quell'area. OTOH disabilitando le sessioni ssl per HTTP avrà un grave effetto sulle prestazioni.

Non vi è alcun punto debole noto riguardo alla ripresa della sessione, poiché è implementato in SSL / TLS . In realtà è qualcosa che è già stato eseguito correttamente in SSL 3.0 e non è cambiato da allora.

Un punto degno di nota è relativo a una situazione in cui si utilizza l'autenticazione client basata su certificato e il client utilizza una smart card che richiede un PIN. Al termine della prima stretta di mano, sul lato client è stata calcolata una firma digitale e il PIN deve essere stato inserito. Se il server accetta di riprendere la connessione, il PIN non sarà nuovamente inserito. Come tale, la ripresa della sessione SSL è in contrasto con il server che tenta di indurre l'utente a inserire nuovamente il suo PIN (per assicurarsi, dal punto di vista del server, che l'utente umano sia "ancora lì"). Si noti che i browser e i sistemi operativi tendono a memorizzare il codice PIN ("per aiutare gli utenti"), pertanto la disattivazione della ripresa della sessione non è sufficiente per ottenere comunque questo tipo di garanzia.

Senza la ripresa della sessione SSL, farai più crittografia asimmetrica sul server (quindi un maggiore consumo di CPU - ma raramente si tratta di un problema reale) e, cosa più importante, userai più larghezza di banda della rete e una latenza di connessione più elevata (la "stretta di mano completa" comporta alcuni più kilobyte di dati e un ulteriore round trip, rispetto alla "stretta di mano abbreviata" che si ottiene con la ripresa della sessione SSL). Pertanto, si consiglia di consentire la ripresa della sessione SSL, in generale.