Prestazioni SSL bidirezionali

Se per "2-Way" intendi "SSL con autenticazione client basata su certificato", allora puoi aspettarti il seguente overhead:

• Il server invia un messaggio CertificateRequest che contiene l'elenco dei nomi della CA radice che il server utilizzerà per convalidare il certificato client. A seconda dell'elenco di tale CA, questo messaggio può avere una dimensione non trascurabile (ad esempio 10 kilobyte). Naturalmente, in qualsiasi configurazione ragionevole, il server dovrebbe accettare solo una o due CA, lasciando questa dimensione del messaggio molto al di sotto di 1 kilobyte (ma molti Windows / IIS non sono molto ragionevoli).
• Il client invia il suo certificato come parte di una catena. La dimensione tipica di un certificato è da 1 a 2 kilobyte e la catena del client conterrà tra 1 e 4 certificati (potrebbe contenere di più, ma se lo fa, allora stai facendo cose strane con la tua PKI).
• Il client calcolerà una firma e il server verificherà la firma. Su un PC di base, con RSA, il tempo di generazione della firma sarà di alcuni millisecondi e la verifica sarà almeno 20 volte più veloce di quella. Se il client utilizza una smartcard, il tempo di generazione della firma sarà probabilmente di circa 1 secondo circa (il collo di bottiglia principale è la velocità di I / O con la scheda).
• Anche la firma dal client viene inviata dal client (circa 260 byte per un RSA a 2048 bit).

L'autenticazione del client con i certificati non comporta alcun roundtrip aggiuntivo, ma significa altri dati durante l'handshake iniziale (come spiegato sopra, fino a poche dozzine di kilobyte) e qualche CPU in più (in quantità simili a ciò che il server deve calcolare comunque). Una volta che questi giochi di certificati sono stati riprodotti, il resto della connessione è identico a quello che si verificherebbe senza un certificato client. Nessun impatto ulteriore.

Inoltre:

• Una volta che un client e un server hanno fatto una stretta di mano con i certificati, entrambi conoscono un segreto condiviso, che possono riutilizzare. Ulteriori connessioni utilizzeranno la stretta di mano abbreviata che non implica crittografia asimmetrica ed è più veloce (in particolare, un roundtrip di rete in meno). Ciò mantiene il costo complessivo basso in un tipico server.
• In molte configurazioni, l'autenticazione del client basata su certificati viene eseguita con una rinegoziazione: il client prima si collega "in modo anonimo" al server, quindi il server richiede un nuovo handshake all'interno della connessione , questo tempo con un certificato cliente. Questo è spesso necessario in un contesto HTTPS, perché il server apprenderà l'URL di destinazione solo quando il primo handshake è stato completato, e solo allora saprà che il client vuole raggiungere una parte del sito che richiede l'autenticazione del client con certificati. Con una rinegoziazione, la seconda stretta di mano significa due roundtrip extra di rete.

L'autenticazione login + password ha un overhead più grande perché dovrai inviare un reindirizzamento a una pagina di accesso e quindi verificare la password. L'elaborazione della pagina di accesso, l'interfaccia grafica supplementare sul client e l'hashing lento sul server per la verifica della password, incorreranno nei costi generali della rete e della CPU, che annullano i costi dei certificati client. Pertanto, passare da login + password a certificati è probabile che abbassare i costi della rete e della CPU sul server.

(Ma certificati significa gestione dei certificati e PKI , e di nuovo costi molto più grandi.)

I certificati client vengono utilizzati per l'autenticazione e la negoziazione delle chiavi in SSL. Viene ancora utilizzata una chiave di sessione, quindi non dovrebbero esserci differenze dopo che è stata stabilita una connessione. Non sono sicuro di quante penalità ci sarebbe per la fase di autenticazione, ma non mi aspetto che sia significativa rispetto al fatto di dover eseguire un hash sicuro su una password. Potrebbe essere più veloce.