Evitare l'handshake SSL per ogni chiamata

In SSL ci sono connessioni e ci sono sessioni .

Una connessione inizia con un handshake e termina quando una delle parti lo dichiara inviando un messaggio di avviso close_notify . I normali browser e server Web manterranno le connessioni aperte per qualche tempo, chiudendole dopo uno o due minuti di inattività; una o più richieste e risposte HTTP vengono inviate su quella connessione. Nei normali contesti HTTPS, esiste una mappatura uno-a-uno tra le connessioni SSL e le connessioni TCP sottostanti: per ogni connessione TCP (alla porta 443), ci sarà una singola connessione SSL, e quando la connessione SSL termina, il la connessione TCP sottostante è chiusa.

Una sessione si riferisce alla crittografia asimmetrica che si verifica in una "stretta di mano completa". Il processo handshake , che si verifica all'inizio di una connessione, riguarda la definizione degli algoritmi e delle chiavi crittografiche che verranno utilizzati per proteggere i dati per quella connessione. Esistono due tipi di stretta di mano:

• L' handshake completo è ciò che fanno un client e un server quando non si conoscono (non hanno parlato in precedenza, o molto tempo fa). Nell'intera stretta di mano, i certificati vengono inviati e si verifica la crittografia asimmetrica (RSA, Diffie-Hellman ...).

• L'handshake abbreviato è ciò che un client e un server si ricordano a vicenda; più accuratamente, ricordano gli algoritmi e le chiavi che hanno stabilito in una precedente stretta di mano e accettano di riutilizzarli (tecnicamente, riutilizzano il "master secret" e ne derivano nuove chiavi di crittografia per questa connessione).

Una connessione con una stretta di mano completa e l'insieme di connessioni con una stretta di mano abbreviata che riutilizzano l'intera stretta di mano, costituiscono insieme la sessione .

L'handshake abbreviato è più efficiente dell'intera stretta di mano, perché implica un numero inferiore di round-trip di rete, messaggi di handshake più piccoli e nessuna crittografia asimmetrica.

Per prestazioni , in generale, desideri quanto segue:

1. Tieni le connessioni aperte il più possibile. Una "connessione aperta" utilizza alcune risorse di memoria (entrambe le parti devono ricordare le chiavi) e le risorse di sistema (per la connessione TCP sottostante, che viene mantenuta aperta). Tuttavia, non vi è alcun traffico di rete coinvolto nel mantenere in vita una connessione, ad eccezione forse del " keepalive TCP " opzionale.

2. Quando le connessioni non possono essere mantenute aperte (ad esempio, per liberare risorse di sistema), è meglio che client e server memorizzino sessioni in modo che possano fare strette di mano abbreviate se si riconnettono. I server Web hanno varie politiche predefinite e configurabili. Ad esempio, Apache (con mod_ssl ) utilizza una cache che è definita sia per taglia e per durata ; il server "dimentica" una sessione quando la sua cache è piena e ha bisogno di spazio aggiuntivo, o quando è stato raggiunto il timeout, a seconda di quale condizione si verifica per prima.

Se si ha il controllo sulla configurazione dei server, è possibile aumentare il "timeout di inattività" per la terminazione della connessione e anche aumentare le dimensioni e la durata della cache della sessione. Se tu non hai il controllo sui server, allora la tua domanda è in qualche modo discutibile: qualunque cosa tu faccia, dovrà essere compatibile con ciò che offrono i server. Puoi in qualche modo forzare un server non a dimenticare una sessione aprendo regolarmente una nuova connessione con una stretta di mano abbreviata, ma non è necessariamente una buona idea (di solito, quando un server dimentica le sessioni, è per un più o meno buona ragione).

Ad ogni modo, devi prendere misure . Questa è una domanda sulla performance; il ragionamento astratto non può dare risposte definitive. La solita regola pratica è che i problemi di prestazioni non esistono finché non sono stati debitamente misurati nella vita reale, o almeno in un sistema prototipo ragionevolmente rappresentativo.

In ogni caso, è difficile ottenere le stesse funzionalità di sicurezza di SSL con un costo inferiore. Sostituire SSL con "qualcosa di personalizzato" è improbabile che fornisca un notevole miglioramento delle prestazioni, senza sacrificare in alcun modo la sicurezza.

Per una panoramica di SSL, vedi questa risposta . Avere una certa conoscenza degli interni SSL ci aiuta molto a pensare a qualsiasi progetto che coinvolga SSL.

Questo dovrebbe essere un commento, dal momento che non ci sono abbastanza informazioni nella tua domanda per diagnosticare il problema / proporre una risposta definitiva, ma è un po 'lungo ....

È piuttosto difficile tel dalla tua domanda come si presenta la tua applicazione. Ti stai riferendo al codice in esecuzione sul tuo server che fa chiamate HTTPS ad altri servizi o le chiamate effettuate dal browser? Le chiamate a un numero prevedibile e ridotto di server?

Se il client per le chiamate HTTPS è il tuo codice di applicazione, otterrai grandi vantaggi dallo sfruttamento keepalive (se supportato dal server HTTPS). A seconda di come funziona la tua applicazione, ciò potrebbe significare gestire un pool di connessioni (che può essere complicato), tuttavia alcuni proxy inversi lo supporteranno.

Forse hai solo bisogno di utilizzare le informazioni di memorizzazione nella cache già fornite dal servizio HTTPS: instradare le richieste tramite un proxy di memorizzazione nella cache locale sarebbe di aiuto.

In alternativa, se controlli i servizi remoti, l'utilizzo di una VPN invece di TLS eliminerebbe l'overhead di handshake (il più delle volte).

Se la convergenza è al cliente, diventa una domanda molto diversa. Se le richieste multiple sono indirizzate principalmente ai server, la soluzione potrebbe essere quella di abilitare la cache della sessione ssl (distribuita). Certamente dovresti abilitare keepalive (so che Ralph Engeschall ha detto che non dovresti farlo con mod_ssl e MSIE - ma quello era un molto molto tempo fa - dal momento che MSIE7 ha riparato la maggior parte dei problemi).